On 13.11.2006 15:50, jan aerts (RI) wrote:
> Hi all,
> 
> I'm trying to create a little library for drawing my data using SVG. One
> of the inherent properties of the drawings that I have to make, is that
> each picture can contain one or more tracks with each track containing
> one or more features (see ASCII art below).
> 
>  +----------------------------picture-+
>  | +----------------------track1----+ |
>  | |                                | |
>  | |  x          x                  | |
>  | |         x               x      | |
>  | |                                | |
>  | |                                | |
>  | +--------------------------------+ |
>  |                                    |
>  | +----------------------track2----+ |
>  | |                                | |
>  | |                     xx         | |
>  | +--------------------------------+ |
>  +------------------------------------+
> 
> As a track can _only_ be defined within a picture, and a feature can
> _only_ be defined within a track, I have set up the classes as follows:
>  class Picture
>    class Track
>      class Feature
>      end
>    end
>  end
> 
> The problem is that some of the properties of a Picture object have to
> be readable for its Track objects. This is _not_ simple inheritance,
> because Picture and Picture::Track are two completely different things.
> As I see it, there are several options:
> (A) either pass those properties as arguments every time you create a
> new Picture::Track object. Not optimal, because the same piece of data
> is copied over and over again.
> (B) set those features as global variables. Not optimal as well.
> (C) something more elegant?

Why don't you just add a member "container" or "parent" to the Feature 
(and maybe also Track) so a Track knows all of its Features and the 
Features all know the Track that they are part of?  That's a common 
idiom for tree storage if you need to navigate both directions (from 
root to leaf and vice versa).

Another note: while I can see why you nest classes that might become a 
bit unreadable.  Also it does not prevent any outside code from 
accessing class Track and Feature - basically just the names get more 
complex through the nesting.  An alternative approach is to just define 
a module as namespace and nest all classes in it.

module PictureApp
   class Picture
   end

   class Track
   end

   class Feature
   end
end

Kind regards

	robert