Interfaces vs Public Class Members

Question

I've noticed that some programmers like to make interfaces for just about all their classes. I like interfaces for certain things (such as checking if an object supports a certain behavior and then having an interface for that behavior) but overuse of interfaces can sometimes bloat the code. When I declare methods or properties as public I'd expect people to just use my concrete classes and I don't really understand the need to create interfaces on top of that.

I'd like to hear your take on interfaces. When do you use them and for what purposes?

Thank you.

Answer 1

I primarily use interfaces for IoC to enable unit testing.

Answer 2

Interfaces are a powerful tool for abstraction. With them, you can more freely substitute (for example) test classes and thereby decouple your code. They are also a way to narrow the scope of your code; you probably don't need the full feature set of a given class in a particular place - exactly what features do you need? That's a client-focused way of thinking about interfaces.

Answer 3

Unit tests.

With an interface describing all class methods and properties it is within the reach of a click to create a mock-up class to simulate behavior that is not within the scope of said test.

Answer 4

On the one hand, this could be interpreted as premature generalization. On the other hand, using interfaces as a rule helps you write code that is more easily composable and hence testable. I think the latter wins out in many cases.

Answer 5

One good use of interfaces is to facilitate loosely coupled code via dependency injection. Even if you plan on having only one implementation of the interface for production purposes, you might want a different implementation for unit testing.

• Interface Injection (Martin Fowler)
• C# sample code for interface injection

Answer 6

Applying any kind of design pattern or idea without thinking, just because somebody told you it's good practice, is a bad idea.

That ofcourse includes creating a separate interface for each and every class you create. You should at least be able to give a good reason for every design decision, and "because Joe says it's good practice" is not a good enough reason.

Interfaces are good for decoupling the interface of some unit of code from its implementation. A reason to create an interface is because you foresee that there might be multiple implementations of it in the future. It can also help with unit testing; you can make a mock implementation of the services that the unit you want to test depends on, and plug the mock implementations in instead of "the real thing" for testing.

Answer 7

I like interfaces:
* to define a contract between parts/modules/subsystems or 3rd party systems
* when there are exchangeable states or algorithms (state/strategy)

Answer 8

It's all about expecting and preparing for change.

One approach that some use (and I'm not necessarily advocating it) is to create an IThing and a ThingFactory.

All code will reference IThing (instead of ConcreteThing). All object creation can be done via the Factory Method.

ThingFactory.CreateThing(some params).

So, today we only have AmericanConcreteThing. And the possibility is that we may never need another. However, if experience has taught me anything, it is that we will ALWAYS need another.

You may not need EuropeanThing, but TexasAmericanThing is a distinct possibility.

So, In order to minimize the impact on my code, I can change the creational line to:

ThingFactory.CreateThing( Account ) and Create my class TexasAmericanThing : IThing.

Other than building the class, the only change is to the ThingFactory, which will require a change from

public static IThing CreateThing(Account a)
{ 
   return new AmericanThing();
}

to 

public static IThing CreateThing(Account a)
{
   if (a.State == State.TEXAS) return new TexasAmericanThing();
   return new AmericanThing();
}

Answer 9

I've seen plenty of mindless Interfaces myself. However, when used intelligently, they can save the day. You should use Interfaces for decoupling two components or two layers of an application. This can enable you to easily plug-in varying implementations of the interface without affecting the client, or simply insulate the client from constant changes to the implementation, as long as you stay true to the contract of the interface. This can make the code more maintainable in the long term and can save the effort of refactoring later.

However, overly aggressive decoupling can make for non-intuitive code. It's overuse can lead to nuisance. You should carefully identify the cohesive parts of your application and the boundaries between them and use interfaces there. Another benefit of using Interfaces between such parts is that they can be developed in parallel and tested independently using mock implementations of the interfaces they use.

OTOH, having client code access public member methods directly is perfectly okay if you really don't foresee any changes to the class that might also necessitate changes in the client. In any case, however, having public member fields I think is not good. This is extremely tight coupling! You are basically exposing the architecture of your class and making the client code dependent on it. Tomorrow if you realize that another data structure for a particular field will perform better, you can't change it without also changing the client code.