Everything has an Interface

Question

Possible Duplicate:
Do I need to use an interface when only one class will ever implement it?

I am taking over a project where every single real class is implementing an Interface. The vast majority of these interfaces are implemented by a single class that share a similar name and the exact same methods (ex: MyCar and MyCarImpl). Almost no 2 classes in the project implement more than the interface that shares its name.

I know the general recommendation is to code to an interface rather than an implementation, but isn't this taking it a bit too far? The system might be more flexible in that it is easier to add a new class that behaves very much like an existing class. However, it is significantly harder to parse through the code and method changes now require 2 edits instead of 1.

Personally, I normally only create interfaces when there is a need for multiple classes to have the same behavior. I subscribe to YAGNI, so I don't create something unless I see a real need for it. Am I doing it all wrong or is this project going way overboard?

What IDE are you using? Eclipse will change the signature of a method in an interface for you when you change it in the class. — Tulains Córdova, Oct 15 '12 at 19:08
Related/Duplicate: [Do I need to use an interface when only one class will ever implement it?](http://programmers.stackexchange.com/q/159813/25936) — yannis, Oct 15 '12 at 19:09
This question was marked as a duplicate, but it seems the responses on this question were different. A general question about applying an interface to a single general class is not the same thing as asking if this rule should be used for every class within an application. — Shane, Oct 16 '12 at 13:28

score 7 · Answer 1 · answered Oct 15 '12 at 19:09

7

This is a straight up violation of the YAGNI principle and I strongly recommend against doing it that way. It is so easy to introduce an interface later when you really need it that you should not even bother creating it up front. I heard this is a quite common pattern among Java folks but don't ask me why, I have no idea.

However, if this is a team project on which you collaborate, you should follow the established standards, even though they are bad.

answered Oct 15 '12 at 19:09

marco-fiset

8,721
9
35
46

4

Or you should push to change the established standards if they are bad. – Bernard Oct 15 '12 at 19:16
1

@Bernard You could do that too, but unless you go back and remove every interface which is implemented only once, you will create inconsistency in the project, which is worse than having a bad standard. – marco-fiset Oct 15 '12 at 19:18

score 5 · Answer 2 · answered Oct 15 '12 at 19:10

This is a common with partial applications of SOLID principles to a project, and not necessarily a bad thing.

Coding against interfaces instead of classes is a reasonable way to maintain Dependency Inversion, and is very useful (some say necessary) for creating testable software components.

However, if your system as exactly 1 interface for every class, and vice versa, you're probably not respecting Interface segregation, and you're almost certainly violating the guideline of You Ain't Gonna Need It.

Consider the cost in development time (now and in the future) of creating interfaces for each class, and evaluate whether better interface segregation would benefit your project. These principles and guidelines exist only to enable you to understand the tradeoffs in various designs, and communicate about them effectively. The decision on which conventions to follow, and how strictly, is in your hands.

Interface segregation principle has nothing to do with having an interface for each class. You can also inject dependencies that are not interfaces. Unless you meant using an IoC container. — marco-fiset, Oct 15 '12 at 19:12
@marco-fiset In many cases, blind cargo-cult application of DI tends to end up with an interface for each class, with these interfaces named exactly for their single implementors. Applying Interface Segregation can help clarify and crystallize intent for many of these interfaces, and make the utility of the interfaces more apparent. The remaining ones that don't make much sense can then be more easily evaluated and possibly redesigned. — Chris Bye, Oct 15 '12 at 19:23

score 1 · Answer 3 · answered Oct 15 '12 at 19:09

Yes, this project is going way overboard. There are two main reasons why this may happen:

The programmer was blindly following some dogma without understanding where it would actually yield benefits and where not
The programmer is doing test-driven development and makes heavy use of a mocking framework for the tests, and that mocking framework does not (or did not, either when the project was created or when the programmer learned the technique) support mocking concrete classes.

score 1 · Answer 4 · answered Oct 15 '12 at 19:10

Having an interface to each class is extreme. You spotted that right.

However, having interfaces implemented by only a single class is not that unusual as you may think. If you are familiar with the Agile principles, they usually say that interfaces belong to the client, which is both logically correct and technically practical. So you may create interfaces to define behavior to the client and compile clients without the real classes available and thus reducing compile times or delivery of modules. Because modules will depend on interfaces, they will be deliverable independently and without a concrete implementation. Than you can just swap implementations as you wish.

If you take this to extreme, you and up with what you see. It's not good at all, but it would be worse to have no interface at all.

score 1 · Answer 5 · answered Oct 15 '12 at 19:11

I know the general recommendation is to code to an interface rather than an implementation, but isn't this taking it a bit too far?

(IMO) yes. If you have an interface with only one implementor, then you don't really need the interface.

That said, many places will always require 2 implementors. The actual implementation and a mock implementation to allow unit testing of the things that consume it. If your object is just data, or can be used by tests in isolation, great.

The other case where interfaces make sense is as a public interface to an API. That can serve as protection to your consumers even if there is only one implementor (for now).

With a modern mocking framework, mocks are generated on the go, without the need to define a mock class by hand or an interface. — marco-fiset, Oct 15 '12 at 19:57

Everything has an Interface

5 Answers5