Applying the label "Parent/Child" on inheritance vs composition

Question

I just stumbled over an interesting problem with naming.

I am writing automated tests for an Object-Relational mapper.

This involves using super-generic classes that exist solely to exercise certain relationships.

My test first involved composition: One object held another object which held a collection of objects:

Entity => ParentComponent => Bag => ChildComponent.

This naming seemed to make sense - one parent had many children.

But then I wanted to expand my tests for a class that inherits from Entity. I instinctively named it ChildEntity

 Entity => ParentComponent => Bag => ChildComponent 
 ^
 |
ChildEntity

This now gets confusing! I'm using Parent/Child labeling to denote inheritance, and I'm also using Parent/Child labeling to denote composition.

Is there some standard labeling nomenclature I can use that differentiates between the two relationship types?

Answer 1

Child is wrong in an inheritence context because it says nothing about the type. If you would model a cat you would not name the class AnimalChild.

When you talk about OO and explain the concept or the place of a class in its inheritence tree you may speak of child. When you name the class the name should convey its purpose.

• Thomas Junk: But you would name a child derived from a cat simply kitten which is derived from kitonwhich is a deminutive of cat which connotates the parent-child-relationship ;) But you are totally right: simply suffixing something with child is not really helpful.

Answer 2

According to this guy, when using composition, the container class is called a "front-end class" while the classes being contained are "back-end classes."

With regards to inheritance, I don't think parent/child is common, nor is it correct (a parent and child in the real world would be the same type of organism). More common for inheritance are the terms ancestor/descendant, supertype/subtype, or superclass/subclass. Subclass is also commonly used as a verb, as in "to make it do X, subclass it and override Y."

Answer 3

In composition, we quite often discuss the issue of "ownership" and the composition relation is quite often named a "has a" relation. So, I believe it would be quite descriptive to name the object Owner/Owned (I am not very happy about the owned part, but I could not find something better for the object owned by the owner).