I frequently come across projects that strictly define an interface for each and every class. 90% of those interfaces feature only a single implementation. Proponents of these “preemptive interfacs” defend this approach as follows:
- In Java one should always program to interfaces to minimize refactoring efforts, when an additional implementation is required.
- Testing is much easier with interfaces, since you can stub or mock objects easily.
- Frameworks, e.g. Spring make use of Java’s proprietary Dynamic Proxies and therefore require interfaces.
While all of those points seem to have some merits, I think they don’t justify the massive increase in number of classes the defining interfaces preemptively entails. Also:
- Factoring out interfaces once multiple implementation are required is a matter of seconds with contemporary IDEs.
- Mocking classes without interfaces is easy with Mockito or other Unit Testing Frameworks.
- Frameworks like Spring can use byte code generation libraries like CGLIB or Javaassist instead of Java’s proprietary Dynamic Proxy mechanism.
Keeping all this in mind, is there really a compelling reason for “preemptive interface” definition or is it a relict of the past and could even be regarded an anti-pattern?
8
An old sage once said:
- You usually don’t create an interface for every class, that would be an afterthought.
- You create interfaces as a design exercise, then you create classes that implement those interfaces.
- You have to think that what you are creating is always a foundation upon which someone else can built some bigger.
- Don’t create little programs, create designs that can grow in an organic way.
- We know you are perfectly capable of hacking a quick, smart and efficient solution to a problem. You are over-qualified for that. What you should strive for is creating a design, a foundation, an API, a framework, however humble they may be.
- Than design part is one of the few funny and edifying things that are still left of this oftentimes impersonal career of ours.
That said, you can always get your IDE to extract an interface of an existing class if you need it, but you get the point.
Bottom line: you don’t draw a blueprint after a bulding is built. You draw the blueprint and then you built the building based on that blueprint. But civil enginneer is a mature discipline.
3
Interfaces exist (speaking of the interface
keyword), so you can define an API for classes, where the implementation does not matter, only the arguments, return types and maybe thrown exceptions.
You should treat classes and their public methods exactly the same, whether they implement an interface or not. Once you realize that, you will see even a class without implementing an interface actually has and in a way is an interface.
Unless a class is defined as final
, testing a normal class
instead of an interface
is just as easy by extending it.
3
You don’t need need an interface for every class. What I do is create interfaces for injectables and implement newables without interfaces http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/.
2