Re: Solving the data inheritance problem
Kaba wrote:
For a concrete example of the need for a common implementation is the
following:
Finally...
Let a Shape be something that can be drawn. The drawing of a Shape is
controlled by control points. For example a circle would be controlled
by two control points: first marks the center of the circle and the
second marks some point on the circle. These are the kind of Shapes
familiar from many vector graphic programs, such as Visio. The behaviour
of the control points should be uniform (mainly, you can move them
around) and should not be dependent on the specific subclass.
This demonstrates a class that has two different properties:
1) It has something that is dependent on a particular subclass: the
drawing. Maybe one could call this "abstract similarity".
2) It has something that is is not dependent on a particular subclass:
the handling of the control points. Maybe one could call this "concrete
similarity".
The problem is to implement this concrete similarity in a good way. I
already have the two solutions that have come up in this thread in my
toolbox.
My worry with placing data in the superclass is that then the
implementers of the subclasses must remember explicitly call the
functions of the superclass, for example in the swap function.
Excuse me, but I don't see how you can support swap for this.
What happens if I do:
Circle c( ... ) ;
Square s( ... ) ;
c.swap( s ) ;
Ditto assignment. Normally, in a polymorphic hierarchy, the
base class declares (but doesn't define) a private operator=,
and we don't think any more about it.
I'm also not too sure about the control points. I'm rather
sceptical that all possible shapes have exactly two control
points, for example. And the semantics of the control points
varies according to the shape: it's the center for Circle, but
one of the corners for Square, for example. Before pronouncing
futher, I'd want to see some concrete use cases. But I think if
you start forcing exactly two control points, etc. you're moving
toward the template method pattern, and that's probably what you
should be using.
Clearly,
if this is forgotten, bad things can happen. In general, I view it as
important to minimize the opportunities for human errors.
A similar technique to the one given by Ondra kind of avoids the
described problem (use virtual functions in the superclass to get access
to the implementation contained in the derived class): then the common
implementation becomes a member of the derived class and is probably
harder to forget when implementing the swap function.
Anything to add or comment?
What is common to all types, and what not? If part of the
implementation is common, you probably want to use the template
method pattern, or perhaps the strategy pattern, depending on
the rest of the application. If none of the implementation is
common, there's no reason not to use the standard abstract class
as interface idiom.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, 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! ]