| Re: Propagating properties [message #13157 is a reply to message #13149] |
Fri, 16 October 1998 00:00  |
steinhh
Messages: 260
Registered: June 1994
|
Senior Member |
|
|
In article <7071ir$or9$1@news.lth.se> Struan Gray
<struan.gray@sljus.lu.se> writes:
> I've decided to set myself a programming excercise in order to
> really get to grips with objects - as opposed to reading the manual
> and fooling myself that I understand it. I am concentrating on a
> program to draw crystal and surface atomic structures, since the
> structure definitions are nicely hierarchical and can easily be
> objectified, and because I need good 3D plotting so I am forced to use
> object graphics.
Ahh - an excellent way to learn objects (actually doing it), and
an interesting application, too. Wish I had the time to do stuff
like this....
> I've been playing with generating arrays of spheres using multiple
> instances of the example 'orb' object. This works nicely and simply
> but I've hit a conundrum. I would like to create an ur-orb which
> represents an element, say Si, with properties such as size and colour
> which are adopted by all the instances of Si in the crystal. A
> problem crops up when after creating the crystal I decide that all the
> Si atoms should be green rather than blue, or that they should be a
> different size. I would like to be able to just edit the ur-orb and
> have the changes propagate automatically, without having to re-create
> the whole crystal from scratch (which takes some time on my computer).
>
> I can think of various ways to deal with the problem. The the two
> most promising are for the ur-orb to maintain a list of dependent
> objects (which seems ugly and slightly defeats the point of object
> programming), or I can subclass 'orb' to create an 'atom' class that
> checks with a specific ur-orb parent every time it draws itself (which
> has a performance hit, and suffers from the lack of a 'copy object' or
> 'copy properties' command discussed here previously). Does anyone
> have a better idea?
Well, somehow, changing the color representation of Si should
be reflected in a change of the color of the polygon(s) that
make up each atom of type Si, before the figure is redrawn.
The question is how to do it.
My $0.05 example:
silicon = obj_new("atom_type",name='Si',color=<yellow>, valence=....)
lithium = obj_new("atom_type",name='Li',color=<red>, valence=...)
atom1 = obj_new("atom",type=silicon,....)
atom2 = obj_new("atom",type=lithium,....)
Each atom keeps a pointer to it's atomic type (there should be
just *one* instance of each type!! Look up a thread from some
time ago about "singletons" (I think?)).
Now, one of two things should be done:
1. During Atom::Init, a call is made to type->register_me,self
That is, the "atom_type" object is responsible of keeping
track of all atoms of its own kind. (Believe me, there's
nothing non-object oriented about this!)
When you say e.g.,
silicon->setproperty,color=<blue>
then silicon immediately tells all the atoms of its own kind
to make the change in their polygons.
2. The Atom::Draw method needs to be rewritten, to update the
color of the polygons based on information from a call to
self.type->getproperty,color=color
Looking at it after writing it down, these two methods are very
similar to your own suggestion, just rephrased somewhat... For
performance reasons I think I would go for #1. And done this way,
it's not at all against the spirit of OO programming. An atomic
type, with all of its atomic properties fit together quite
naturally - and it's something that you'd like to have more than
one instance of, since there are more than one atomic type, so
make it an object.
An atom as such is the "prototype" of an object - but it's not
necessary to specify e.g. Li as a subclass of "Atom" (though it
*could* be done!). However, each atomic instance that represents
Li should point to the same "definition object", or else you'd
risk having several types of Lithium hanging around!
Regards,
Stein Vidar
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
