Is there any point to an interface if only one class implements it?

Question

Looking at the (mature) codebase at my new job, there is an interface, and only one class implements it (as far as I can tell). Can/should I get rid of the interface?

It looks like you need to flip a coin :) – Romain Hippeau May 18 '10 at 02:53 — Romain Hippeau, May 18 '10 at 02:53

score 9 · Answer 1 · answered May 18 '10 at 01:56

9

No way! Its has zero harmful effects and one day somebody can swap an implementation without having to refactor tons of code.

answered May 18 '10 at 01:56

John Farrell

24,673
10
77
110

By "tons of code", do you mean that another class could be written with a different implementation of the interface, and could be passed into methods expecting a variable implementing that interface without changing the method signatures? Any other examples of refactorings that could be avoided by keeping the interface and implementing a new class? – user343587 May 18 '10 at 02:32
@user343587 Yes, but what if you need two different implementations of that interface and have to swap them out runtime? Sure, you could abstract base it but then your still in the same boat. – John Farrell May 18 '10 at 23:01

score 5 · Answer 2 · answered May 18 '10 at 02:46

5

In addition to the good answers already provided - if at some point in the future that one class needs to be mocked for testing purposes, it's a lot easier to do so when there's already an interface available!

answered May 18 '10 at 02:46

John Rasch

62,489
19
106
139

score 3 · Answer 3 · answered May 18 '10 at 01:57

3

Today, no. Six months from now after the project has grown tenfold in complexity? Who knows. To your point, if this is legacy code, there is little value to an interface that is implemented once, but there is also no point to going through the refactoring involved in removing it. "If it works, don't fix it".

answered May 18 '10 at 01:57

Bob Kaufman

12,864
16
78
107

1

Tidier, less confusing code? Isn't that a point of refactoring? – user343587 May 18 '10 at 02:35
1

Does the interface serve to organize, document or identify? If so, leave it alone! If it's just clutter, then refactoring could be in order. – Bob Kaufman May 18 '10 at 12:54
I don't know what could be so confusing. I have tons of single use interfaces in my code. – John Farrell May 18 '10 at 23:01

score 3 · Answer 4 · answered May 18 '10 at 02:43

Since you mention a mature base, I'd like to mention another real world example: Hibernate's Session.

Session is an interface implemented only by one class: SessionImpl. However, if you've used hibernate in the past, or read its source code, you probably have noticed how Session is used everywhere, instead of SessionImpl.

Is this wrong design? Definetly no. Its called 'The substitution principle', or 'programming towards interfaces'. It means that by using the interface instead of the implementation, you can extend your code without any effort, just instantiating your new classes accordingly, but always using the interface. Will it still be wrong if no one creates a new class implementing Session? No, still not wrong.

My two cents.

score 1 · Answer 5 · answered May 18 '10 at 02:01

Apart from the reasons given in the other answers, only implementing an interface allows intercepting methods by building proxies without using instrumentation. This is used for logging, encapsulating operations in a transaction, etc. It is used by several frameworks.

score 1 · Answer 6 · answered May 25 '10 at 16:10

I would say it depends, but in most cases an interface is a good idea on certain classes. Mocking is made easier using interfaces and when you use an IoC container, then interfaces start making a lot of sense, especially when you start implementing services shared across the container. You will then be able to decouple the implementation of the service from the class needing the service.

score 0 · Answer 7 · answered May 18 '10 at 01:56

0

Yes, there is a point to interfaces, as there could conceivably be more than one implementation in the future. You can of course go overboard here and create interfaces for everything, so there is a balance to be found.

answered May 18 '10 at 01:56

Yann Ramin

32,895
3
59
82

score 0 · Answer 8 · answered Jan 12 '23 at 15:09

I find the inclusion of an interface when you know it's never going to be implemented by anything other than that one class is just annoying. Typically, I have my code editor set up such that I hit a function key to navigate to the definition of the function. When an interface is present, I end up in the interface definition instead of the implementation. Then I have to go find the actual implementation. The amount of time this has cost me has more than made up for the time spent in removing and re-implementing that interface. I have occasionally removed such an interface, and I've never found a need to re-implement one I decided to remove. In terms of unit testing, modern mocking systems have completely removed the need for having that interface.

score -1 · Answer 9 · edited May 23 '17 at 10:30

Even if people don't quite agree on the number of bug per 1000 lines of code, those two seem correlated (https://stackoverflow.com/questions/862277/what-is-the-industry-standard-for-bugs-per-1000-lines-of-code). Less lines == less bugs.

Also, changing the name of the implementation for the name of the interface should be all there is to do here.

If the refactoring effort is minimal and it reduces the code, I'll be rather for the supression of the interface.

Is there any point to an interface if only one class implements it?

9 Answers9