Eric I. wrote:
> Hi Steve,
>
> You can decide whether the objects form a hierarchy in which the higher
> level objects know about the underlying levels (and not vice versa), or
> whether the lower level objects can/should know about "whom" they
> belong to.  And this really depends on what makes sense for the
> information domain you're working in.
>
> Think about instances of a class PostalAddress.  That's a pretty
> general purpose class, and you can imagine using it in many
> circumstances -- in a Customer class, an Employee class, an Invoice
> class, etc.  In that case you would likely not want to have
> PostalAddress have an instance variable that refers back to the
> instance to which it belongs.  There's no purpose for this information
> that could span all these different uses.
>
> Now consider two highly cooperative classes, say an Account class and a
> Transaction class.  An Account will likely have a reference to many
> Transactions.  And it would be reasonable for a Transaction to have a
> reference back to the Account it belongs to.
>
> Now I don't know the information domain you're working with.  But you
> can ask yourself whether it's reasonable for an instance of drive to
> know about which tape library it belongs to.  If it is reasonable, then
> the constructor for a drive *should* take as a parameter a reference to
> the tape library and store that in an instance variable.
>
> In other words, your solution is basically OK and may not be as much as
> a "kludge" as you are inclined to believe.  You may want to consider
> using an attribute name more specific than @parent, though, as it
> sounds like you know what type this parent should be.
>
> Eric
>

Thanks Gents.

Your posts have made the lightbulb come on :)
I need a device class and a drivedevice class descended from it, which
has the extra information that it needs.

Many Thanks

Steve

AIX and TSM Admin
Brisbane Australia
> ====
> Highly reviewed, hands-on, on-site Ruby training is available from
> www.LearnRuby.com .