Oh yes!
So you suggest that my 'toolchest' of things be put into a 'normal' module and be imported into the OO module. That makes sense!
My problem is that I read the book and nod sagely, but when it comes to sitting at the keyboard it doesn't make that much sense any more! Thanks for the clarification.
jdtoronto
| [reply] |
my 'toolchest' of things be put into a 'normal' module and be imported into the OO module
Your toolchest doesn't necessarily have to be a procedural ("normal") module, it too can be object oriented. diotalevi is only suggesting that the relationship between your toolchest module and your application module doesn't appear to be one where inheritance is appropriate.
Inheritance is for when one thing is another thing, where as delegation is when one thing has another thing. These are commonly refered to as is-a and has-a relationships. This is why inheritance in Perl is done through the @ISA array. Delegation in Perl can be accomplished simply by storing one object as an attribute in another object, and calling the first object's methods as appropriate.
To further reinforce the point, consider describing your situation in these terms. Does it make more sense to say "my application is a toolbox" or "my application has a toolbox"? Compare to a frequent example where inheritance is used: "this cat is a mammal" vs "this cat has a mammal." That should help you decide which is appropriate.
| [reply]
[d/l] |
How do I use the "has-a" relationship?
Say I have a paw object that is used by many of my objects, like the cat object. I'd use it like $cat->paw->scratch, but how would cat.pm use implement the paw.pm?
| [reply] |
My problem is that I read the book and nod sagely, but when it comes to sitting at the keyboard it doesn't make that much sense any more!
Such is the curse of OO design guidelines: putting them into practical use.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
| [reply] |