how to change mindset from Records to objects

[zyzygy]

Hi Gang,

I have a ruby issue that I'm hoping someone can shed some light on. Its
probably not so much a Ruby issue as a dinosaur ex Cobol programmer
trying to work with objects rather than records.

I'm using Ruby to generate ConTeXt code to automate a report. One part
of the data is about tape libraries and looks something like this
(simplified)

tapelibs:Array
tl:Tapelib
lib_deviceevice
rmuevice
parts:Array
partartition
drives:Array
driveevice


I'm creating this data in part from an input file and in part from
stored database information, and the whole tree of objects is created
so that the Initialize of one object calls the initialize of the next
sub object as needed.

One of the attributes of Device is latest_ucode and it is looked up in
the database.

Now it turns out that the latest microcode level for a drive depends on
the type of the tape library as well as the type of the drive, so when
I'm down in the depths of of Initialize for the Device object I need to
access the tape library model several steps up the data structure.

The only way that I have been able to work around this is to pass Self
down into the creation of the next level object and use that to create
a @parent attribute, which I can then follow back up as necessary.

This feels kludgy and unsatisfying though and is not nearly general
enough for my taste.

Can someone please point me at the Ruby way to do this?


Thanks

Steve.

 

[Dolazy]

(e-mail address removed) schreef:

Hi Gang,

I have a ruby issue that I'm hoping someone can shed some light on. Its
probably not so much a Ruby issue as a dinosaur ex Cobol programmer
trying to work with objects rather than records.

I'm using Ruby to generate ConTeXt code to automate a report. One part
of the data is about tape libraries and looks something like this
(simplified)

tapelibs:Array
tl:Tapelib
lib_deviceevice
rmuevice
parts:Array
partartition
drives:Array
driveevice


I'm creating this data in part from an input file and in part from
stored database information, and the whole tree of objects is created
so that the Initialize of one object calls the initialize of the next
sub object as needed.

One of the attributes of Device is latest_ucode and it is looked up in
the database.

Now it turns out that the latest microcode level for a drive depends on
the type of the tape library as well as the type of the drive, so when
I'm down in the depths of of Initialize for the Device object I need to
access the tape library model several steps up the data structure.

The only way that I have been able to work around this is to pass Self
down into the creation of the next level object and use that to create
a @parent attribute, which I can then follow back up as necessary.

This feels kludgy and unsatisfying though and is not nearly general
enough for my taste.

Can someone please point me at the Ruby way to do this?


Thanks

Steve.

If I understand well, you are saying that in order to define a drive
you must know what tape library you are using. So in that case I think
passing the type library object to the constructor of the drive object
is the right choice.

Transitioning from Cobol to Ruby is a brave choice! I hope you'll enjoy
it

Francis

 

[Eric I.]

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 .

 

[zyzygy]

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