Some time ago, looking at an overhaul of a Java API I worked with, I said: "Sometimes a class is just a class."
This was in response to the introduction of Java interfaces for virtually everything in that API. The person doing the redesign was thinking that every class used in more than one file must have its own interface. We would have had java.lang.IString if he had a saying in this.
Let me explain why I did not like it.
The redesign did not take into account that there is a cost to abstraction. Interfaces give the implementor the freedom of choice, but the user will have to cope with a greater variety.
Interfaces require investments in:
- Documentation: An interface has more stringent documentation requirements. The behavior of the interface must be defined for users and implementors.
- Learning: classes are easier to understand than interfaces, especially when you can look at the code of the class. (Check yourself: when someone asks you about an edge case in a piece of code you have written 6 months ago, do you look into the documentation or the actual statements?)
- Testing: Instead of testing one class, client code will in most cases need tests against the different implementations. Combinatorial explosion, here we come.
- Change Management: interfaces most often cannot grow easily, (final) classes can. When one changes an interface, even by only adding one method, all implementations become moot. The common way out is to defined a 2nd interface which can extend the first one. This then is more clumsy for clients to use since they need
instanceofand multiple execution paths which again need more test effort for their code.
Therefore, sometimes a class is better just a class. Don't follow the cargo cult into abstracting everything...