Re: Solving the data inheritance problem
Lourens Veen wrote:
Kaba wrote:
It occurs to me that maybe we're looking at this from the wrong
end. It seems to me that these control points are actually more
important than the shapes they are part of. How about making a
Document class that has a set of control points, which each have a
pointer to the Shape they are part of, and a set of shapes, which
would have pointers back to their control points rather than
containing them.
A new shape is created and owned by a Document, which keeps track
of it and its control points. All it would need to know is how many
control points there are for a shape, which is easily added as a
constant to the derived class. The Document can then move a control
point without even knowing which object it belongs to or what the
type of that object is.
I like this viewpoint. It can well be a solution for me, but I still
have to cast it to my specific problem (other than this Shape thing)
and think more of it to get familiar with it. Btw, osn't this the
flyweight pattern?
I'm not very good with patterns, but I don't think so. The idea of the
flyweight pattern is that if you have a lot of objects that share
part of their state, then you can factor out that part and give each
object a pointer to a shared state object instead. That saves room.
In this case, neither control points nor shapes are shared or sharing
anything.
I don't know what it would be though. I guess the Document becomes a
sort of collection. Can anyone tie a pattern to this?
I'm also not very good with patterns. The always seem somewhat trite to
me when I explore them.
I'd written up a variation on your idea (I'd not read your posts at
that time) which I describe as instance bahaviour. I think that the
extra seperation I add in is critical to succesful use of the idiom.
In my scheme the document would probably hold something like this for
the shapes:
std::map< int, Shape > shapes;
The map being there in order to have a Z-order on the shapes held so we
know how they overlap. In my formulation the shape still holds its
points, but also holds another object which actually represents the
primitive that is being drawn based on those control points.
Without the extra layer I think you would need something like this in
the document:
std::map< int, std::pair< std::list< Point >, Shape > > shapes;
Which gives the ability to change the shape for a given set of control
points, but now seems to give the document too much to do.
K
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]