Maximum Accepted Layers/Levels of inheritance

Hi,

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) ?
On what does this depend upon ?

Thx in advans,
Karthik Balaguru

re: Maximum Accepted Layers/Levels of inheritance

[CC'd to a design newsgroup, because the answer is not specific to C++]

karthikbalaguru wrote:
Don't...

- design all your classes "up front" before
coding any of them
- use inheritance as a "compilable comment"
- use public data
- abuse protected data - use virtual accessors instead
Good software...

- passes all automated tests
- is clear and readable
- duplicates no behavioral code
- minimizes lines, methods, and classes

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.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath

re: Maximum Accepted Layers/Levels of inheritance

karthikbalaguru wrote:
a) If you are talking about coding guidelines, then any number could be your
superiors personal upper bound of acceptability:-)

b) If you are talking about whether the compiler will accept your code, the
standard [Annex B] recommends that an implementation supports classes with
up to 16384 direct and indirect base classes. Whether you want to go that
far, is up to you.
For (a), experience, taste, and local culture.

For (b), the implementation.


Best

Kai-Uwe Bux

re: Maximum Accepted Layers/Levels of inheritance

Phlip wrote:Eschew obfuscation, though.

Also be careful of http://en.wikipedia.org/wiki/Abstraction_inversion

Also, minimizing the number of classes should not be made by creating
http://en.wikipedia.org/wiki/God_object

re: Maximum Accepted Layers/Levels of inheritance

Responding to Phlip...

Mostly for the OP's benefit...
Using testing as a product reliability gate only works to something
approaching 5-Sigma. Even then it is only a necessary condition, not a
sufficient condition.

Beyond 5-Sigma testing must monitor the development process rather than
the product. In that situation one needs to test until enough tests fail
to provide a reasonable statistical sampling. IOW, the testing is
inadequate unless enough tests fail. (Obviously if one knows a defect
exists after monitoring the process, one usually wants to fix it prior
to customer shipment but that is a different process stage once one has
monitored the process with testing.)
Normal Form applies to knowledge attributes as well as behavior
responsibilities.
This is only relevant in 3GL development. In a translation environment
one never even looks at the 3GL code so none of this matters. In fact,
at the 4GL level all dependency management refactoring is irrelevant
because there is none of the physical coupling present in 3GL type systems.

If one is developing in an elaboration environment, then dependency
management becomes critical to provide 3GL maintainability due to
physical coupling in the 3GLs. However, that is solving a developer
problem rather than the customer problem. So one Good Software also
requires avoiding architectural drift during the dependency management
refactoring.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

re: Maximum Accepted Layers/Levels of inheritance

James Kanze wrote:
penguin --|flighted_bird

This great post by Tim Ottinger says it best:

----8<-------------------------------

Ell wrote:
No, though it ought to be. We're trying to make it so. But in most shops
where I've worked before OMA, most shops my friends work at, many
places where we're brought in to teach, and the majority of shops where
other teachers I know teach, abstraction is not understood in the light of
dependency management and risk management. It's just a way of taking a wild
swag at the structure of a system.

Inheritance is typically used too much, and usually wrongly. It's most
frequently used to denote inappropriate dynamic set memberships, create
inappropriate couplings of orthogonal aspects of objects, or even worse as
"compilable comments".

If most programmers are taught how to do this in Intro To Programming 101,
then 101 needs a serious reworking. For details of how people typically do
this incorrectly, read "What Every Programmer Should Know About OOD",
chapters 8-12.

--
Phlip

re: Maximum Accepted Layers/Levels of inheritance

James Kanze wrote:
That's why I was very careful to say "behavioral" code. That's generally the
live executable statements that add value. A subset of the statements that
(in C++) you could put a debugging breakpoint on.

--
Phlip

re: Maximum Accepted Layers/Levels of inheritance

James Kanze wrote:
I wrote that because I didn't have /DP/ to hand. I suspect that no pattern
in /DP/ has more than two layers, and I suspect this answers the OP. 2.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
http://tinyurl.com/23tlu5 <-- assert_raise_message

re: Maximum Accepted Layers/Levels of inheritance

Phlip <phlip2005@gmail.comwrote:
I don't think there should be any maximum number of "accepted layers".
Make it as deep as you want. However, I think that all base classes in
C++ should contain only pure-virtual functions and no data (i.e.,
interface classes.)

re: Maximum Accepted Layers/Levels of inheritance

Daniel T. wrote:
You can't mean that. What's the deepest real-code example you have
available?

Note that our arch-enemy here is junior programmers writing

Hylidae --|Anura --|Amphibia --|Chordata --|Animalia

for no other reason than the target program contains taxa of tree-frogs. The
correct implementation would probably be the Composite Design Pattern,
which has 2 levels of inheritance.
Isn't this putting the cart before the horse? What if, for some given
real-code situation, a few implementations should be in the base class.
Yes, that's just a convenience. Moving them down, at refactor time, should
be trivial. So just leave them there. The other arch-enemy here is junior
programmers behaving as if designs must never be changed...

--
Phlip

re: Maximum Accepted Layers/Levels of inheritance

Phlip <phlip2005@gmail.comwrote:To answer your questions, I've been known to write hierarchies 3-4
levels deep, and no I don't think it's putting the cart before the horse.

I have encountered no "real code situation" where "a few implementations
should be in the base class" in C++. Rather if several derived classes
all share common data and methods, I put them in a delegate class that
they all use. There is no "moving them down" because they were never in
the base class to begin with. (Note: my answer is different in a dynamic
typed language like Python.)

As for your tree-frog example. If I have a class that uses the Chordata
class and passes its Chordata objects to a class that uses the Amphibia
class and it passes objects to a class that uses the Anura class and it
passes them to a class that uses the Hylidae class, then I see nothing
wrong with the hierarchy as you have presented it. Such a situation is
obviously very rare. Maybe twice in the past 10 years.

re: Maximum Accepted Layers/Levels of inheritance

Daniel T. wrote:
The ideal "no implementation in base classes" struck me as a "prosthetic
goal". Switching metaphors here. The real goals should be code that passes
all tests, is clear and expressive, duplicates no behavior, etc. You will
probably get that, whatever the language, with lean base classes.
Right, but the motivation was separating concerns.
Yet you did not start your design by declaring that a proposed Amphibia
object should inherit a proposed Chordata object, based entirely on their
names. You probably found a real virtual method for the concrete classes to
implement, in a way that folded together duplicate behaviors. And twice in
10 years confirms our "Zipf's Law" hunch that the answer to the OP's
question is still "almost always 2!"

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
^ assert_xpath
http://tinyurl.com/23tlu5 <-- assert_raise_message

re: Maximum Accepted Layers/Levels of inheritance

On Sep 11, 7:49 pm, Phlip <phlip2...@gmail.comwrote:I suspect that as well, although I once used a pattern which
required 4. (It was a very special case, however, and related
to the fact that we were generating much of the code
automatically.) And mixins require a minimum of 3, and 4 often
makes them clearer. What I was really meant to get at, however,
is that when you compose patterns, you will often end up with 3
or maybe 4 levels. It's not a problem *IF* the patterns
involved and the composition is clear.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: Maximum Accepted Layers/Levels of inheritance

On Sep 12, 2:43 am, Phlip <phlip2...@gmail.comwrote:

[Google won't show me the original posting you are
responding to, so I'll comment it here.]Make it as deep as you have to. In many ways, the shallower the
better, but of course, there are more important criteria which
may push the level up a little. I'd be suspicious if, in an
application, more than about 5% of the hierarchies were deeper
than 3, and I'd probably at least glance at those hierarchies,
just to make sure that the depth was justified.
Which ignores some important patterns, like the template method
pattern. Also, of course, in C++, it's fairly rare for public
functions to be virtual; the usual idiom is to use public
functions to specify the interface, including the contract (pre-
and post-conditions), and have them forward to private virtual
functions for the implementation details.
Totally agreed. We define a solution, without having specified
a problem.
If the contract says that they must have a specific interface,
then yes, they belong in the base class. If it's just a
convenience, it's often preferable to put them in an
intermediate class, if only to reduce compilation dependencies
(but I find that it helps readability as well). At any case,
it's a judgement call.
On large projects, a junior programmer doesn't have the right to
change the design himself. At least not if the change involves
changes in the interface, which breaks other peoples code. (But
I agree with the thrust of your comment. Just replace "junior
programmers" with "pointy-haired managers".)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

re: Maximum Accepted Layers/Levels of inheritance

James Kanze wrote:
/Don't/ try to make friends with me! (-;

--
Phlip