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

====
Highly reviewed, hands-on, on-site Ruby training is available from
www.LearnRuby.com .