Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'll cite some passages from <a href="http://rads.stackoverflow.com/amzn/click/0321413091" rel="noreferrer">Implementation Patterns</a> by Kent Beck:</p> <h2>Simple Superclass Name</h2> <blockquote> <p>"[...] The names should be short and punchy. However, to make the names precise sometimes seems to require several words. A way out of this dilemma is picking a strong metaphor for the computation. With a metaphor in mind, even single words bring with them a rich web of associations, connections, and implications. For example, in the HotDraw drawing framework, my first name for an object in a drawing was <strong>DrawingObject</strong>. Ward Cunningham came along with the typography metaphor: a drawing is like a printed, laid-out page. Graphical items on a page are figures, so the class became <strong>Figure</strong>. In the context of the metaphor, <strong>Figure</strong> is simultaneously shorter, richer, and more precise than <strong>DrawingObject</strong>."</p> </blockquote> <h2>Qualified Subclass Name</h2> <blockquote> <p>"The names of subclasses have two jobs. They need to communicate what class they are like and how they are different. [...] Unlike the names at the roots of hierarchies, subclass names aren’t used nearly as often in conversation, so they can be expressive at the cost of being concise. [...]</p> <p>Give subclasses that serve as the roots of hierarchies their own simple names. For example, <em>HotDraw</em> has a class <strong>Handle</strong> which presents figure- editing operations when a figure is selected. It is called, simply, <strong>Handle</strong> in spite of extending <strong>Figure</strong>. There is a whole family of handles and they most appropriately have names like <strong>StretchyHandle</strong> and <strong>TransparencyHandle</strong>. Because <strong>Handle</strong> is the root of its own hierarchy, it deserves a simple superclass name more than a qualified subclass name. </p> <p>Another wrinkle in subclass naming is multiple-level hierarchies. [...] Rather than blindly prepend the modifiers to the immediate superclass, think about the name from the reader’s perspective. What class does he need to know this class is like? Use that superclass as the basis for the subclass name."</p> </blockquote> <h2>Interface</h2> <blockquote> <p>Two styles of naming interfaces depend on how you are thinking of the interfaces. Interfaces as classes without implementations should be named as if they were classes (<em>Simple Superclass Name</em>, <em>Qualified Subclass Name</em>). One problem with this style of naming is that the good names are used up before you get to naming classes. An interface called <strong>File</strong> needs an implementation class called something like <strong>ActualFile</strong>, <strong>ConcreteFile</strong>, or (yuck!) <strong>FileImpl</strong> (both a suffix and an abbreviation). In general, communicating whether one is dealing with a concrete or abstract object is important, whether the abstract object is implemented as an interface or a superclass is less important. Deferring the distinction between interfaces and superclasses is well >supported by this style of naming, leaving you free to change your mind later if that >becomes necessary.</p> <p>Sometimes, naming concrete classes simply is more important to communication than hiding the use of interfaces. In this case, prefix interface names with “I”. If the interface is called <strong>IFile</strong>, the class can be simply called <strong>File</strong>.</p> </blockquote> <p>For more detailed discussion, buy the book! It's worth it! :)</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