Object Oriented Heuristics wrote:
Chapter 5
The Inheritance Relationship
Heuristic #5.1
Inheritance should only be used to model a specialization hierarchy.

Heuristic #5.2
Derived classes must have knowledge of their base class by definition, but
base classes should not know anything about their derived classes.

Heuristic #5.3
All data in a base class should be private, i.e. do not use protected data.

Heuristic #5.4
Theoretically, inheritance hierarchies should be deep, i.e. the deeper the
better.

Heuristic #5.5
Pragmatically, inheritance hierarchies should be no deeper than an average
person can keep in their short term memory. A popular value for this depth is
six.

Heuristic #5.6
All abstract classes must be base classes.

Heuristic #5.7
All base classes should be abstract classes.

Heuristic #5.8
Factor the commonality of data, behavior, and/or interface as high as
possible in the inheritance hierarchy.

Heuristic #5.9
If two or more classes only share common data (no common behavior) then that
common data should be placed in a class which will be contained by each sharing
class.

Heuristic #5.10
If two or more classes have common data and behavior (i.e. methods) then those
classes should each inherit from a common base class which captures those data
and methods.

Heuristic #5.11
If two or more classes only share common interface (i.e. messages, not
methods) then they should inherit from a common base class only if they will be
used polymorphically.

Heuristic #5.12
Explicit case analysis on the type of an object is usually an error, the
designer should use polymorphism in most of these cases.

Heuristic #5.13
Explicit case analysis on the value of an attribute is often an error. The
class should be decomposed into an inheritance hierarchy where each value of
the attribute is transformed into a derived class.

Heuristic #5.14
Do not model the dynamic semantics of a class through the use of the
inheritance relationship. An attempt to model dynamic semantics with a static
semantic relationship will lead to a toggling of types at runtime.

Heuristic #5.15
Do not turn objects of a class into derived classes of the class. Be very
suspicious of any derived class for which there is only one instance.

Heuristic #5.16
If you think you need to create new classes at runtime, take a step back and
realize that what you are trying to create are objects. Now generalize these
objects into a class.

Heuristic #5.17
It should be illegal for a derived class to override a base class method with a
NOP method, i.e. a method which does nothing.

Heuristic #5.18
Do not confuse optional containment with the need for inheritance, modelling
optional containment with inheritance will lead to a proliferation of classes.

Heuristic #5.19
When building an inheritance hierarchy try to construct reusable frameworks
rather than reusable components.

Chapter 6
Multiple Inheritance
Heuristic #6.1
If you have an example of multiple inheritance in your design, assume you have
made a mistake and prove otherwise.

Heuristic #6.2
Whenever there is inheritance in an object-oriented design ask yourself two
questions: 1) Am I a special type of the thing I'm inheriting from? and 2) Is
the thing I'm inheriting from part of me?

Heuristic #6.3
Whenever you have found a multiple inheritance relationship in a
object-oriented design be sure that no base class is actually a derived class
of another base class, i.e. accidental multiple inheritance.

Chapter 7
The Association Relationship
Heuristic #7.1
When given a choice in an object-oriented design between a containment
relationship and an association relationship, choose the containment
relationship.