[SOLVED] Best practice for naming subclasses

Best practice for naming subclasses

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.

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

Solution

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