When are interfaces needed?

Question

(In the context of .NET for what its worth)

I tend to not use inheritance and rarely use interfaces. I came across someone who thinks interfaces are the best thing

Answer 1

It is about dependencies. You want your code to depend on interface types instead of concrete types where appropriate. For example, you might have multiple concrete types that all perform similar behavior but implement it differently. Do you want your code base to have dependencies on those multiple concrete types, or one interface? How flexible do you think your code base will be when you need to make changes?

To your point about not wanting to use public members by using composition, I would say you're just encapsulating unnecessary dependencies. If you want to use composition, then you greatly reduce dependencies by composing interface types instead of concrete types.

For a better explanation, try looking at the literature on inversion of control.

Answer 2

Interfaces make the most sense to me in the context of dependency injection and IoC frameworks. I like the idea that you can define a set of behaviors (methods) and "guarantee" those behaviors through the implementation of an interface. Now you can plug whole new functions into an existing system with a single assembly and a config file update.

Effective design of interfaces does require a good deal of forward planning, and I find they are most useful in the context of large systems and frameworks. When they're useful they're really useful. A few of my favorite:

• IComparable (YOU decide how your objects compare against each other)
• IQueryable (LINQ anyone?)
• IDisposable (keep your using statement handy)

Answer 3

We heavily use interfaces on custom UI elements, where each one is expecting a certain method to exist on another (and the interface forces that existence).

Answer 4

The primary use of an interface is to allow the variation of implementation allowing code to be switched at runtime. There are a number of reasons/rationale for doing this.

In the past some have argued that every class in the system should have an interface, but this is widely recognized as overkill. Interfaces are now used where instances of classes either can change as part of the system operation (to represent state): GoF patterns like Strategy and Command capture this use, and/or parts of the system need to be replaced for testing (ie. dependency injection). If developers are following test-driven development practices the key infrastructure objects will have interfaces. This allows tests to make "mocks" of these objects to test the system's flow-of-control. There is a relationship between this use of interface and the Liskov Substitution Principle (one of the principles of OO design)

A further use for interfaces which is less concerned with what is available to the caller, is the marker interface. Which is a way of associating metadata with the class definition. This may affect how the system views the object (for example allow it to be Serialized) or it might just serve as documentation.

Answer 5

It sounds like your friend was seriously mis-using interfaces.

I've also seen web apps with interfaces all over the place. Some people seem to have the idea that an interface is somehow better than just a regular method signature. Simple parameters already provide us with a contract--in most cases I believe this is enough, and makes for simpler code.

It seems to me that interfaces are most useful in cases like IDisposable or ICollection -- where they point to a certain set of functionality to expect from an object. In these cases they appear to be the right tool for the job.

Answer 6

I'd refer to the .net design guidelines on this: http://msdn.microsoft.com/en-us/library/ms229013.aspx

There are a lot of reasons to use interfaces, but I also find that they're often overused for the wrong reasons. Interfaces provide much more flexibility when working with value types, and are incredibly useful when working with collections, etc, but when designing a class hierarchy for my own projects, I always try to think about simplicity first, and interfaces often lead to (unnecessarily) more complex situations.

My rule of thumb is to implement every BCL interface that makes sense, and only add my own interfaces into my designs when it actually provides something very valuable. Instead of having IWidgetManager, IWidgetManager2, etc... I'd much rather have abstract class WidgetManager and implement concrete methods as needed.