.NET - Can you over interface, and when shouldn't you interface.

Question

Is it possible to over interface? when designing an system now, I will start from interfaces and progressively write unit tests along with the interfaces until I have a pattern that works well.. I'll move onto writing some concrete classes and set the unit tests up against these..

Now I'm someone who loves interfaces, I will generally end up only ever passing/returning primatives or interfaces around when I control the code.. so far I've found this to be ideal, you can easily adapt and enhance a system generally without impacting the dependent systems.

I obviously don't need to sell the reasons for using interfaces, but im wondering if its overboard to interface everything, ps. I'm not talking about blank interfaces as in something crazy like:

interface IStringCollection : ICollection<string>
{
}

I'm talking more something like:

interface ISomethingProvider
{
  ISomething Provide(ISomethingOptions options);
}

Is this really over the top? my reasoning is that any type could gain from interfacing at some point.. and the only real problem I've had is that I've had to learn what I think is a better way to design classes, as you don't have daft interactions and 'hacks' going on.

Would love your feedback about if this is a timebomb, and when you decide to interface vs not..

ps- this isn't really so much about how to write interfaces.

Answer 1

ISwissArmyKnife!

Consult this:

http://thedailywtf.com/Articles/Classic-WTF-Implements-ISwissArmyKnife.aspx

Answer 2

It can be a real pain to work out the eventual call stack before you step with the debugger if you have interfaces everywhere. I tend to prefer interfaces only when:

1. you need team members to agree on who should do what before they start coding - an interface then documents the border exactly
2. when you actually need an interface to solve the problem, so at least two implementations that don't extend each other
3. You expect case 2

Answer 3

I find that interfaces complicates the design, especially for other people to cowork on your stuff. Don't get me wrong, interfaces are great for a lot of stuff, but mostly if you want two or more classes to share a common interface.

If you find yourself in the situation where you suddenly need an interface, refactoring with tools like Resharper is a breeze :)

Answer 4

As with anything else - use with moderation and where necessary. Ask yourself "Are you gonna need it?".

Answer 5

Interfaces describe a contract for behavior. If you need to address some set of objects according to a behavioral pattern, interfaces are useful, not so much if you're simply describing the structure of objects. I think you need to have a good reason to use them, such as using a factory that creates behaviorally related objects or establishing a behavioral contract for part of a library. Using interfaces aimlessly can make a library difficult to read / understand / maintain.

Answer 6

This isn't solely a .NET thing, the same problem occurs in Java quite often.

Unless it's a completely obvious requirement, I vote for not using interfaces and simply refactoring when the need becomes clear.

The pragmatic approach says to just do the simplest thing that could possibly work, and don't get caught in architecture astronautics.

Answer 7

In short yes it is possible to over interface a project. Take into account when the situation really calls for an Abstract Base Class and an interface, while they both are similar there are distinct advantages to using both See Here. Typically I've noticed that people use Interfaces when they really should be using Abstract Base Classes. From a OO perspective interfaces should be used to list common behavior that may span vastly different classes. For example you may have an IMove interface with a method called Move(). Now imagine you have an Airplane, Car, Person, and Insect class. Airplane and Car may inherit from an abstract Vehicle class but still need to use IMove and so will Insect and Person but they will all implement move differently. I've noticed, my self included, people tend to use Interfaces to "group" classes together when really that should be handled by a base class.

Answer 8

I tend to not use too many interfaces for testing purposes. I would rather make a private value public and/or unsealing classes and/or temp methods while building and testing until I am at the point where I have built other objects and tests that will eventually exercise what it was that i needed. Sometmes its a pain in the butt to rack your changes that way but your tests will tell you when you forgot to change something.

Answer 9

It is possible to over-interface. The rule where I work is that if you have an interface in your application, you need to have at least two classes that implement it (or have a reasonable expectation that you will be adding implementing classes in the near future).

If you need to create mock objects for testing, then having the mock class and the real class implement a common interface is a valid reason to use an interface.

I would not recommend automatically using interfaces for everything in your application, especially because a single class can usually be easily refactored into an interface if necessary.

Answer 10

Whenever I see or hear someone say this

Interfaces describe a contract for behavior

I know I've found someone who doesn't understand interfaces.

Interfaces cannot do that. It is impossible. Interfaces do not prescribe, force, or in any way constrain behaviour.

Interfaces describe a contract for an interface, hence the name. They do not have behaviour.

You might hope that the names you give your interface's methods will imply a required behaviour to anyone implementing it, but there is no requirement that they do so. There is no behavioural contract, nor can there ever be one.

If you require a certain type of behaviour then you must use classes to enforce it (eg with the Template pattern) - that's where all the behaviour is.

Interfaces are regularly abused as a design construct, and one of the reasons is because of widespread belief in this fallacy.