Best practice for naming subclasses

Question

I am often in a situation where I have a concept represented by an interface or class, and then I have a series of subclasses/subinterfaces which extend it.

For example: A generic "DoiGraphNode" A "DoiGraphNode" representing a resource A "DoiGraphNode" representing a Java resource A "DoiGraphNode" with an associated path, etc., etc.

I can think of three naming conventions, and would appreciate comments on how to choose.

---

Option 1: Always start with the name of the concept.

Thus: DoiGraphNode, DoiGraphNodeResource, DoiGraphNodeJavaResource, DoiGraphNodeWithPath, etc.

Pro: It is very clear what I am dealing with, it is easy to see all the options I have

Con: Not very natural? Everything looks the same?

---

Option 2: Put the special stuff in the beginning.

Thus: DoiGraphNode, ResourceDoiGraphNode, JavaResourceDoiGraphNode, PathBaseDoiGraphNode, etc., etc.

Pro: It is very clear when I see it in the code

Con: Finding it could be difficult, especially if I don't remember the name, lack of visual consistency

---

Option 3: Put the special stuff and remove some of the redundant text

Thus: DoiGraphNode, ResourceNode, JavaResourceNode, GraphNodeWithPath

Pro: Not that much to write and read Con: Looks like cr*p, very inconsistent, may conflict with other names

Answer 1

Use whatever you like, it's a subjective thing. The important thing is to make clear what each class represents, and the names should be such that the inheritance relationships make sense. I don't really think it's all that important to encode the relationships in the names, though; that's what documentation is for (and if your names are appropriate for the objects, people should be able to make good guesses as to what inherits from what).

For what it's worth, I usually use option 3, and from my experience looking at other people's code option 2 is probably more prevalent than option 1.

Answer 2

Name them for what they are.

If naming them is hard or ambiguous, it's often a sign that the Class is doing too much (Single Responsibility Principle).

To avoid naming conflicts, choose your namespaces appropriately.

Personnally, I'd use 3

Answer 3

Option three more logically follows from the concept of inheritance. Since you're specializing the interface or class, the name should show that it's no longer using the base implementation (if one exists).

There are a multitude of tools to see what a class inherits from, so a concise name indicating the real function of the class will go farther than trying to pack too much type information into the name.

Answer 4

You could find some guidance in a coding standards document, for example there is the IDesign document for C# here.

Personally, I prefer option 2. This is generally the way the .NET Framework names its objects. For instance look at attribute classes. They all end in Attribute (TestMethodAttribute). The same goes for EventHandlers: OnClickEventHandler is a recommended name for an event handler that handles the Click event.

I usually try to follow this in designing my own code and interfaces. Thus an IUnitWriter produces a StringUnitWriter and a DataTableUnitWriter. This way I always know what their base class is and it reads more naturally. Self-documenting code is the end-goal for all agile developers so it seems to work well for me!

Answer 5

I usually name similar to option 1, especially when the classes will be used polymophically. My reasoning is that the most important bit of information is listed first. (I.e. the fact that the subclass is basically what the ancestor is, with (usually) extensions 'added'). I like this option also because when sorting lists of class names, the related classes will be listed together. I.e. I usually name the translation unit (file name) the same as the class name so related class files will naturally be listed together. Similarly this is useful with incremental search.

Although I tended to use option 2 earlier in my programming career, I avoid it now because as you say it is 'inconsistant' and do not seem very orthogonal.

I often use option 3 when the subclass provides substantial extension or specification, or if the names would be rather long. For example, my file system name classes are derived from String but they greatly extend the String class and have a significantly different use/meaning:

Directory_entry_name derived from String adds extensive functionality. File_name derived from Directory_entry_name has rather specialized functions. Directory_name derived from Directory_entry_name also has rather specialized functions.

Also along with option 1, I usually use an unqualified name for an interface class. For example I might have a class interence chain:

• Text (an interface)
• Text_abstract (abstract (base) generalization class)
• Text_ASCII (concrete class specific for ASCII coding)
• Text_unicode (concrete class specific for unicode coding)

I rather like that the interface and the abstract base class automatically appear first in the sorted list.