Re: Solving the data inheritance problem
Kaba wrote:
Hello, I'd like to discuss about solutions to the following general
problem:
Given is an abstract class A (that is, contains at least one virtual
function). The derived classes of A are called B[i] (indexed by i).
A more concrete example would be appreciated. Form follows
function, and it is difficult to determine the best form is we
don't know the function.
The main purpose of inheritance is interface inheritance: this is to say
that all B[i] have commonly describable behaviour.
Now assume that the B[i] also have data in common: every B[i] will
contain the same block of data which is accessed using a fixed set of
functions.
If I now make the data handling functions virtual functions of A, I will
end up implementing identical boiler-plate code for each B[i]
implementation. This naturally raises objection: code replication should
be avoided.
The question now is: how do you model common data between B[i] without
replicating code?
It depends. If the presence of specific data and specific,
concrete data handling is an invariant of A, the data and the
handling belong in A, not in B[i]; this is the template method
pattern, and is widely uses. (Maybe too widely---most of the
time, I find that the strategy pattern is preferrable.)
A straightforward solution is the following: place the data in A and
implement the (non-virtual) handling functions there. I call this data
inheritance.
The standard nomenclature calls it the template method pattern.
This solution has the following draw-back:
Consider any function of B[i] that has to modify all of the data.
Examples include the assignment operator, the ubiquituous swap-function,
and constructors. The problem is that you have to remember to take care
of the parent data also! For example, in the B[i] assignment operator, B
[i] must call the assignment operator of A. Same applies to swap. The
problem is: what can be forgotten, will be forgotten.
For starters, if your class is really polymorphic, then you
don't want to support assignment or swap---they suppose value
semantics, and polymorphism only works with reference semantics.
(There are ways to get around this, such as the letter/envelope
idiom. But they address the problems directly.) As for
constructors, you can't avoid calling base class constructors,
the compiler insists, so there is no problem there.
For other functions, the basic solution of the template pattern
is the opposite: it is the functions in the base class which
call virtual functions for the derived class to do whatever
extra it has to do, and not the inverse. (If you're using the
template pattern, your virtual functions will all be private
anyway, so users cannot call them.)
It should'n be that the solution places this kind of burden on the
implementor of B[i].
It would help if you'd explain the actual problem. It sounds
like you're trying to use pure interfaces where what you want
and need is the template pattern.
--
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]