Should Interfaces be kept as generic as possible?

Question

When developing interfaces, should they be kept as generic as possible or should you try to put as many methods, properties in an interface to keep the number of interfaces low: As an example, which is better 1 or 2:

1) Customer and Rental split into 2 interfaces (Data only relevant to a rental is in Rental interface and data only relevant to a customer is in the Customer interface)

interface ICustomer { public string Name { get; set; } public string Address { get; set; } public string Phone { get; set; } public string Email { get; set; } } interface IRental: ICustomer { string Title { get; set; } decimal Cost{ get; set; } void Rent(); }

2) Put all data into one interface.

interface IRental { string Title { get; set; } decimal Cost{ get; set; } void Rent(); public string Name { get; set; } public string Address { get; set; } public string Phone { get; set; } public string Email { get; set; } }

Also regarding the first approach, is there a benefit to extending the ICustomer interface or should there just be an ICustomer property in IRental like the following:

interface IRental { ICustomer customer {get;set;} string Title { get; set; } decimal Cost{ get; set; } void Rent(); }

What are the advantages/disadvantages of the approaches above? and is there a preferred way (one that is more scalable and maintainable).

I think that generally, the one that makes the most sense in your model. I think rental is not a customer, so it should not inherit from it. — svick
– svick, Commented Oct 20, 2011 at 15:11
I think it makes more sense for a rental to have a customer. Unless you're renting customers... — Michael Petito
– Michael Petito, Commented Oct 20, 2011 at 15:14
@Michael but inheritance reads "is a", if a rental has a customer, expose a property. If a rental is a customer, inherit. — Adam Houldsworth
– Adam Houldsworth, Commented Oct 20, 2011 at 15:15
@AdamHouldsworth I'm pretty sure we're saying the same thing. My point is that if a rental is a customer (IRental : ICustomer) then calling Rent() of IRental implies to me that you're renting something that is a customer. — Michael Petito
– Michael Petito, Commented Oct 20, 2011 at 15:24

Anthony Pegram · Accepted Answer · 2011-10-20 15:20:29Z

Look into the Interface Segregation Principle of SOLID. Fat interfaces can be problematic, implementers and consumers are forced to care about more things than they need. Keep your interfaces thin and highly focused. An example used is often the concept of a modem

interface Modem { void Dial(); void Hangup(); void Send(); void Receive(); }

Implementers of Modem have to provide implementations for dialing and hanging up, which are connection state issues. And then provide implementations for sending and receiving, which are data transfer issues. These should possibly be two unique interfaces, they are two different groups of responsibilities, which also goes into the Single Responsibility Principle. And not all modems might need both sets of responsibilities.

Thanks for pointing out the Interface Segregation Principle and showing an example. I was also thinking the same thing when you mentioned that all implementors may not need to implement everything an interface provides, further telling me it is better to break it down

Wojteq · Accepted Answer · 2011-10-20 15:14:01Z

You should always take under consideration Single responsibility principle. Classes, methods and interfaces should be domain specific items. So IMHO it's better to separate ICustomer and IRental.

Adam Houldsworth · Accepted Answer · 2011-10-20 15:47:30Z

There is no golden rule.

Personally, I only break stuff down when I need to or when it makes sense. This usually means understanding what the interface is trying to expose and breaking up logically different contracts.

Interfaces should always be geared to exposing a specific contract for a specific purpose - this will likely mean they are thin on the ground. It stops people interested in your interface from having to expose things they don't need to subscribe to.

In your case, IRental and ICustomer are two logically separate entities. A rental might contain customer details, but it should do so in a customer class, not via flat properties. So your last code looks most sensible to me:

interface IRental { ICustomer customer {get;set;} string Title { get; set; } decimal Cost{ get; set; } void Rent(); }

What is the difference between the last example and IRental : ICustomer
@Xaisoft IRental : ICustomer associates the types, IRental is an ICustomer. IRental.ICustomer simply says IRental contains an ICustomer property. Inheritance is a big topic, worth reading into separately.
Ok, I see what you are saying, I guess it would be dumb to think that a Rental is-a Customer or a Customer is-a Rental.

Sabre · Accepted Answer · 2011-10-20 15:15:09Z

I would go option 1, it allows you to edit interfaces independently.

As Adam points out "always uses", I would be scared of that term, it can be a hard corner to find yourself in when a design spec changes or years later upgrading.

Stealth Rabbi · Accepted Answer · 2011-10-20 15:16:18Z

It depends on your data model, but if a Customer can have more than one rental, or if there's ever potential for this, it doesn't make sense for a Rental to have the customer information in case 2.

A rental is not a Customer, so option 1 doesn't really fit. Ask yourself "Is Rental a type of Customer or a specialization of Customer"?

A third option that you are hinting at, for an IRental to have a reference to an ICustomer probably makes sense, assuming you can't have a Rental without a Customer.

Ragoczy · Accepted Answer · 2011-10-20 15:14:59Z

I'd say that the example mixes things too much. Rental and Customer are two different types of entities.

At first glance, I'd say that you have Customer, Title and Rental types, where a Rental references a Customer and a Title.

 public class Customer { string Name { get; set; } string Address { get; set; } string Phone { get; set; } string Email { get; set; } } public class Title { string Name { get; set; } decimal Cost { get; set; } } public class Rental { Customer Renter { get; } Title Media { get; } DateTime Due {get;} public void Rent(Customer, Title); }

I'm not sure interfaces enter into it until you have a can-do association -- possibly around the rental itself.

Punit Vora · Accepted Answer · 2011-10-20 15:20:38Z

One thing that comes to my mind is the Interface Segregation Principle from the SOLID Principles. Instead of providing one fat Interface, it is good to split up the interfaces if you think some clients might not need to implement all the methods/properties of that interface. It also probably makes your intentions for asking the client to implement the interface more clear by explicitly telling them that you want certain methods implemented for certain specific functionality

For the Second part of your question, I think again the tenet of using "Composition over Inheritance" may apply, though this depends on the exact problem you are trying to solve. If Customer is a behavior that can be switched at runtime, then you should use it as a member of the IRental interface which is basically the premise of the Strategy Design Pattern.

supercat · Accepted Answer · 2011-10-20 15:52:30Z

It may be good for a IRental to have a field PrimaryCustomer, of type ICustomer, and possibly something a IList<Customer> called something like RelatedCustomers (in case, e.g. a customer has indicated that he plans to use an item with some other people who are also customers; such information may be useful if there's an issue with the rental but the customer cannot be reached). IRental should probably only inherit ICustomer, however, if every customer is going to rent exactly one thing.

Otherwise, suppose Rental1 and Rental2 both have a Name of "John Smith". After 'Rental1.Name = "Fred Jones"', what would Rental2.Name be? It would be unclear whether Rental1 and Rental2 refer to the same customer. If there were a Customer property, such ambiguity would go away. If Object.ReferenceEquals(Rental1.Customer, Rental2.Customer), then changes to Rental1.Customer.Name would affect Rental2.Customer.Name (it's the same property, of the same object). If Rental1.Customer is a different object from Rental2.Customer, then changes to one should not affect the other.

Incidentally, I would suggest that it might be good to define an interface IReadableCustomer, in which the properties just have "getters", and have ICustomer inherit from IReadableCustomer (ICustomer would have to add a "new" qualifier to its property definitions to avoid silly "ambiguity" messages). In C#, such a change would not require any extra code for implementations of ICustomer, but would allow better control over who was allowed to make changes to a customer record.

Collectives™ on Stack Overflow

Should Interfaces be kept as generic as possible?

8 Answers 8

1 Comment

Comments

3 Comments

Comments

Comments

Comments

Comments

Comments

Hot Network Questions