Re: Maximum Accepted Layers/Levels of inheritance
On Sep 10, 8:18 pm, Phlip <phlip2...@gmail.com> wrote:
karthikbalaguru wrote:
What could be the maximum Accepted Layers/Levels of inheritance in a
normal C++ program that has private(data),protected(data) and
public(data,member functions) ?
Don't...
- design all your classes "up front" before
coding any of them
But do design your classes to work together (which means
designing more than one at a time).
- use inheritance as a "compilable comment"
I'm not sure what you mean by this.
- use public data
- abuse protected data - use virtual accessors instead
On what does this depend upon ?
Good software...
- passes all automated tests
- is clear and readable
- duplicates no behavioral code
- minimizes lines, methods, and classes
The last is, of course, in definite contradiction to the second
and the third. Avoiding code duplication will up the number of
functions and possibly the number of classes, and minimizing
lines doesn't always improve readability---if not, APL would be
the most readable language around.
But these are mostly secondary considerations, derived from the
two principle considerations: good software is functionally
correct (i.e. it's behavior conforms to the requirements
specification), and is easy to maintain. Automated tests are a
necessary (but not sufficient) condition of the first, and clear and
readable is a necessary (but not sufficient) condition of the
second. You're third and fourth points are generally minor
issues, and don't always hold.
Start with the book /Design Patterns/, generally to learn what
the "point" of all this OO stuff is. You will notice most
patterns use only 2 layers of inheritance - an abstract
interfacial class, and concrete classes that inherit from it.
Too much inheritance is a "design smell", because inheritance
is one of the strongest forms of "coupling", and we should
instead want classes with carefully managed dependencies
between things.
The key above is "most patterns". This is, in some ways,
something like the discussion on function length. There is no
absolute limit, but if most hierarchies end up with more than
two or three levels, it's a suspicious symptom, worth looking
into. I'd guess that about 90% of my hierarchies are just an
interface and a set of derived implementations: two levels.
Sometimes the derived implementations will use the template
method patter, which bumps it up to three, and sometimes it
makes sense to insert an abstract level between the interface
and the implemention, with some commonly needed convenience
functions. And some very special patterns, like mixin, do
involve more (four or five levels), but they are fairly rare.
Note too that the can be technical reasons for using C++
inheritance, unrelated to the design issues. It's not rare for
generated code to double the number of levels, and I've seen
cases in low level code where inheritance was used instead of
containment in order to allow empty base class optimization
(often the case for the allocators in the standard library), or
for reasons of exception safety (i.e. to allow "partial"
destruction of a partially constructed object). I would not
count either of these in the designed depth.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34