Name your Interface what it is
If your interface is a
Truck, call it
ITruck because it isn’t an
ITruck it is a
Truck. An Interface in Java is a Type. Then you have implementations of
CementTruck, etc. When you are using the Interface
Truck in place of a sub-class you just cast it to
Truck. As in
I in front is just crappy Hungarian style notation tautology that adds nothing but more stuff to type to your code.
All modern Java IDEs mark Interfaces and Implementations and what not without this silly notation. Don’t call it
TruckClass that is tautology just as bad as the
The only real exception to this rule that I accept, and there are always exceptions is
AbstractTruck when the class is package local. Since only the sub-classes will every see this and you should never cast to an Abstract class it does add some information that the class is abstract and to how it should be used. You could still come up with a better name than
AbstractTruck and use
DefaultTruck or some other more descriptive name instead. But since Abstract classes should never be part of any public facing interface it is an acceptable exception to the rule.
If it is an class it is an implementation
Impl suffix is just more noise as well. More tautology. Anything that isn’t an Interface is an Implementation, even Abstract classes which are just partial implementations. Are you going to put that silly
Impl suffix on every name of every Class? It makes no more sense than suffixing every Class with
The Interface is a contract on what the public methods and properties have to support, it is also
Type information as well. Everything that implements
Truck is a
Look to the Java standard library itself. Do you see IList, ArrayListImpl, LinkedListImpl? No you see. List and ArrayList and LinkedList. Any of these silly prefix/suffix naming conventions all violate the DRY principal as well.
Also if you find yourself adding
BEAN or other silly repetitive prefixes or suffixes to object names then they probably belong in a package instead of all those suffixes. Properly packaged namespaces are self documenting and reduce all the useless redundant information in these really poorly conceived proprietary naming schemes that most places don’t even adhere to in a consistent manner. If all you can come up with to make your Class name unique is suffixing it with
Impl, then you need to rethink having an Interface at all. So when you have an situation where you have an Interface and a single Implementation that is not uniquely specialized from the Interface you probably don’t need the Interface.
If you can’t give unique descriptive names to your Interfaces and Classes, you are doing it wrong.
Mocking the Mocking Argument
It has been argued that putting a
Mock prefix or suffix on classes is a good idiom to mark the classes as Mock implementations, why not call them
MockImpl if you are going to argue that?
Assuming that the real classes are in
com.company.app.service. Mock implementations should be in their own
com.company.app.service.mock package, ideally in a different directory structure with the
Test classes, as in Maven, which will allow them to have the same names as the non-Mock classes, and still document that they are Mocks for testing only, and not pollute the name space of the production code and make it easy to not-include that code in the deployment.