What's the best approach to naming classes?

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! :)

Always go for MyClassA, MyClassB - It allows for a nice alpha sort..

I'm kidding!

This is a good question, and something I experienced not too long ago. I was reorganising my codebase at work and was having problems of where to put what, and what to call it..

The real problem?

I had classes doing too much. If you try to adhere to the single responsibility principle it will make everything all come together much nicer.. Rather than one monolithic PrintHandler class, you could break it down into PageHandler , PageFormatter (and so on) and then have a master Printer class which brings it all together.

In my re-org, it took me time, but I ended up binning a lot of duplicate code, got my codebase much more logical and learned a hell of a lot when it comes to thinking before throwing an extra method in a class :D

I would not however recommend putting things like pattern names into the class name. The classes interface should make that obvious (like hiding the constructor for a singleton). There is nothing wrong with the generic name, if the class is serving a generic purpose.

Good luck!

Josh Bloch's excellent talk about good API design has a few good bits of advice:

• Classes should do one thing and do it well.
• If a class is hard to name or explain then it's probably not following the advice in the previous bullet point.
• A class name should instantly communicate what the class is.
• Good names drive good designs.

If your problem is what to name exposed internal classes, maybe you should consolidate them into a larger class.

If your problem is naming a class that is doing a lot of different stuff, you should consider breaking it into multiple classes.

If that's good advice for a public API then it can't hurt for any other class.