Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Name your <code>Interface</code> what it is. <code>Truck</code>. Not <code>ITruck</code> because it isn't an <code>ITruck</code> it is a <code>Truck</code>. </p> <p>An <code>Interface</code> in Java is a <a href="http://java.sun.com/docs/books/tutorial/java/IandI/interfaceAsType.html" rel="noreferrer">Type</a>. Then you have <code>DumpTruck</code>, <code>TransferTruck</code>, <code>WreckerTruck</code>, <code>CementTruck</code>, etc that <code>implement Truck</code>. </p> <p>When you are using the <code>Interface</code> in place of a sub-class you just cast it to <code>Truck</code>. As in <code>List&lt;Truck&gt;</code>. Putting <code>I</code> in front is just crappy hungarian style notation <a href="http://en.wikipedia.org/wiki/Tautology_%28rhetoric%29" rel="noreferrer">tautology</a> that adds nothing but more stuff to type to your code. </p> <p>All modern Java IDE's mark Interfaces and Implementations and what not without this silly notation. Don't call it <code>TruckClass</code> that is <a href="http://en.wikipedia.org/wiki/Tautology_%28rhetoric%29" rel="noreferrer">tautology</a> just as bad as the <code>IInterface</code> tautology. </p> <p>If it is an implementation it is a class. The only real exception to this rule, and there are always exceptions, could be something like <code>AbstractTruck</code>. Since only the sub-classes will ever see this and you should never cast to an <code>Abstract</code> 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 <code>AbstractTruck</code> and use <code>BaseTruck</code> or <code>DefaultTruck</code> instead since the <code>abstract</code> is in the definition. But since <code>Abstract</code> classes should never be part of any public facing interface I believe it is an acceptable exception to the rule. Making the constructors <code>protected</code> goes a long way to crossing this divide.</p> <p>And the <code>Impl</code> suffix is just more noise as well. More tautology. Anything that isn't an interface is an implementation, even abstract classes which are partial implementations. Are you going to put that silly <code>Impl</code> suffix on every name of every <a href="http://java.sun.com/docs/books/tutorial/java/concepts/class.html" rel="noreferrer">Class</a>? </p> <p>The <code>Interface</code> is a contract on what the public methods and properties have to support, it is also <a href="http://java.sun.com/docs/books/tutorial/java/IandI/interfaceAsType.html" rel="noreferrer">Type</a> information as well. Everything that implements <code>Truck</code> is a <a href="http://java.sun.com/docs/books/tutorial/java/IandI/interfaceAsType.html" rel="noreferrer">Type</a> of <code>Truck</code>. </p> <p>Look to the Java standard library itself. Do you see <code>IList</code>, <code>ArrayListImpl</code>, <code>LinkedListImpl</code>? No, you see <code>List</code> and <code>ArrayList</code>, and <code>LinkedList</code>. Here is a nice <a href="https://web.archive.org/web/20130331071928/http://isagoksu.com/2009/development/java/naming-the-java-implementation-classes" rel="noreferrer">article</a> about this exact question. Any of these silly prefix/suffix naming conventions all violate the <a href="http://www.artima.com/intv/dry.html" rel="noreferrer">DRY</a> principle as well.</p> <p>Also, if you find yourself adding <code>DTO</code>, <code>JDO</code>, <code>BEAN</code> or other silly repetitive suffixes to objects then they probably belong in a <a href="http://java.sun.com/docs/books/tutorial/java/package/packages.html" rel="noreferrer">package</a> 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 internally adhere to in a consistent manner. </p> <p>If all you can come up with to make your <code>Class</code> name unique is suffixing it with <code>Impl</code>, then you need to rethink having an <code>Interface</code> at all. <strong>So when you have a situation where you have an <code>Interface</code> and a single <code>Implementation</code> that is not uniquely specialized from the <code>Interface</code> you probably don't need the <code>Interface</code>.</strong></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload