I see it a lot in code: interface ISomething, class Something. No other implementation of ISomething. Why do programmer do that? It seems useless, and annoying because when walking through the code, you have to search for that one implementation every time to see what is going on. Okay for information hiding you actually should not have to do that, but still. Why having an interface for something that has only one implementation, and will most likely not have more implementations in the future.
In the present case it is a class that loads a configuration file with nuget specifications. Something with a build system. The class and interface are 5 years old, and I cannot think of a situation where you would want to load that information in another way, making a second implementation of that class. It seems a little like a programmer took the advise 'you can better use an interface over a class' somewhat too rigid. I agree that using an interface hides information, and separates usage from implementation. But to me this only seems beneficial if you would have more implementations. If you always have only one, it is like you disperse information over two files that are logically always linked together. If not necessary, put information about one subject in one place. Or am I missing something?
One valid scenario could be the case where you only have one production implementation but perhaps one or more non-production implementations to facilitate unit or integration testing. If this is not true in your case then I would tend to agree that the original programmer went too far and added complexity where it wasn't really necessary. Reminds me of what Sandi Metz once tweeted:
In a Tweet, Sandi Metz wrote:Don't write code that guesses the future, arrange code so you can adapt to the future when it arrives.
After some more reading through the code, I see that the interface is used in a Mock<ISomething> object for a unit test. So that probably is the reason. But then the question is should you complicate your code to make unit tests writing easier.
Thanks for your thoughts about the issue, J. Lacar and R. Twede!
Jan de Boer wrote:But then the question is should you complicate your code to make unit tests writing easier.
That kind of leads you to the "turtles all the way down" answer. You have to strike a balance between complexity and ease (programming/maintaining/testing). If you want to make your code testable, a certain degree of flexibility is needed. Flexibility carries with it the cost of complexity. The more flexible code is, the more complex it tends to be. Again, I would go back to Sandi Metz: only make the code as flexible as you need it to be for the current requirements, not for requirements you anticipate having in the future. This is true for both testing as well as functional/production requirements.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
No it's not useful. One of the principles of eXtreme Programming is "You ain't gonna need it (=YAGNI)". It states that you should only add stuff to your codebase when you actually need it.
Not just to foresee something that might never come in the future. So when you only have 1 implementation, forget about the interface unless you NEED it. Later, when you must add a second implementation, you can always add the interface and refactor.
Oracle Java SE6 Certified Programmer
Oracle Java EE5 Certified Web Component Developer
Pivotal Certified Spring Professional
You don't like waffles? Well, do you like this tiny ad?