Whether we are writing DAO’s, services or use case, most of the time we create interfaces for these implementations. It allows us to program against interfaces, a common best practice for all of us. Using interfaces gives us following advantages:
- Enables loose coupling between interacting classes
- Makes it easier to test
- Allows us to easily switch between implementations.
Lately, I’ve been openly questioning if we should always use interfaces. Are they always required by default and is the extra cost of keeping the interface and the implementation in sync worth the trouble? Lets discuss.
When we are using dependency injection, the coupling between one class and another is very low. It’s of course true that by injecting implementation instead of interfaces we are making the coupling a little tighter. The classes are still in isolation, since neither creates a new instance. This is still done by the DI container, which deals with instantiation and configuration.
Is a class that only has interfaces as dependencies easier to test then classes that have implementations as dependencies? Most of us are eager to say yes, but in fact, frameworks like EasyMock enable us to mock (non final) classes. We can add behavior just like any other interface.
When writing an application, it’s very rare to change the implementation of an interface. Almost all my interfaces have exactly one implementation. Sometimes this is not the case naturally, but I find it pretty easy to spot those implementation that might or will change in the near foreseeable future.
If we should reduce the amount of interfaces in our code, the advantages could be:
- Less classes which (should) equal to less configuration and maintenance
- Less synchronization during development so results in a little faster velocity
Anyway, this is purely speculative.
Let me state that I’m not thinking about actually dumping the interfaces. It’s a proven practice, but I’m think out loud and for myself. What I’m looking for is an insight or story that will convince me either way. So if you have any, I’m more then eager the hear!
Andries
Andries,
Although interfaces are useful, they should be used with care.
I personally believe interfaces offer a way to safely connect different modules and/or packages of a project. Within a package, interfaces are rarely useful, with the exception of defining a common ‘interface’ of different classes.
Anyway, with the IDEs we use nowadays it is dead simple to extract an interface from a given class whenever we need it.
I think the best examples of interface use are design patterns such Command, Strategy, State or even the Proxy pattern. They are all based on interfaces for increased flexibility and reuse.
Objects can also implement many interfaces, but only extend one class (inheritance could be considered as a compile time dependency). An example of object reuse: you can divide the public methods of an object over multiple interfaces based on its use from the clients, to make it usable from different viewpoints. The same object could be used by different clients, each time with another interface. That same object would be reusable in different circumstances (but be careful for anti-patterns).
I am of the school of thought that you touch upon here – which is really questioning the use of interfaces.
Interfaces I think have a place, especially if the software you are working on will be packaged and used by others. There are of course other instances when you interfaces are indeed called for (e.g. you will have more than one implementation, want to simulate multiple inheritance or in specific design patterns such as Observer pattern).
But when you are working on something that is specifically for yourself I am not sure it is really needed.
When I ask some people why should I use an interface they allude to the same points you mentioned.
- Ease of testing – solved by a number of test frameworks
- More than one implementation – in my programming experience the times when you will have a single implementation vastly outnumber the multiple.
Interested to hear peoples thoughts.
The fact that EasyMock, or other mocking frameworks, enable you to bypass the interface when mocking is immaterial – after all, I *could* test private functions as well. Or, use post-compilers to inject my own code.
The point of unit testing isn’t only the testing – it’s the seams that (if done properly) it forces you to put in to enable that testing. Interfaces are one such seam.