I’ll cite some passages from Implementation Patterns by Kent Beck:
Simple Superclass Name
“[…] 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
DrawingObject. 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 Figure.
In the context of the metaphor, Figure
is simultaneously shorter, richer, and
more precise than DrawingObject.”
Qualified Subclass Name
“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. […]Give subclasses that serve as the
roots of hierarchies their own simple
names. For example, HotDraw has a
class Handle which presents figure-
editing operations when a figure is
selected. It is called, simply, Handle
in spite of extending Figure. There is
a whole family of handles and they
most appropriately have names like
StretchyHandle and TransparencyHandle.
Because Handle is the root of its own
hierarchy, it deserves a simple
superclass name more than a qualified
subclass name.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.”
Interface
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
(Simple Superclass Name, Qualified Subclass Name). One problem with this style of
naming is that the good names are used up before you get to naming classes. An
interface called File needs an implementation class called something like
ActualFile, ConcreteFile, or (yuck!) FileImpl (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.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 IFile, the class can be simply called File.
For more detailed discussion, buy the book! It’s worth it! 🙂