good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re: Names of attribute accessors (Moose)by Athanasius (Archbishop) |
on Oct 23, 2015 at 13:33 UTC ( [id://1145758]=note: print w/replies, xml ) | Need Help?? |
Hello v_melnik, I’m having trouble understanding your OO design. In part, I suspect it’s a problem of terminology. For example, you say: I'm passing the reference to the parent object to the child object... But in OO there’s no such thing as a “parent object” or a “child object.” There are parent and child classes, related by inheritance, but the inheritance relation does not extend to objects. For example, if you had a parent class Dog and a child class Labrador_Retriever, you could create two objects:
but it would be wrong to refer to $rex as the “parent” of $fido in this case. Actually, it’s also usually a bad design to allow a parent class like Dog to be instantiated at all. Dog should be an abstract base class. In Perl, there’s an additional source of confusion in the naming scheme of the module hierarchy. For example, if you use two classes like this:
it seems natural to assume that Foo::Bar is a child class of Foo. But that needn’t be the case; Foo::Bar may be completely unrelated to Foo. The package name Foo::Bar simply tells Perl to search for the Bar package in a directory named Foo. To create an inheritance relationship (in Moose) you would normally use extends:
Now to the real issue: inter-object communication. You write: I'm passing the reference to the parent object to the child object, because I need the child to have access to the parent and its methods & accessors. Why? If there’s a true inheritance relationship, then a child class object already has access to the methods in the parent class. In all other cases, communication between objects should be via the public interfaces of those objects. That — encapsulation — is a large part of what OO is all about! And if you have to subvert encapsulation to a large extent (as your use of attributes appears to be trying to do), that would tend to indicate a basic flaw in the OO design. But I apologise if I’ve misunderstood the design issue behind your question. If so, will you please explain why standard, public-interface-based communication between objects is inadequate to your requirements? Also, exactly what problem is the attribute-based design you’ve outlined intended to solve? Try to provide a short, self-contained example showing communication between two or three objects. Hope that helps,
In Section
Seekers of Perl Wisdom
|
|