On Wed, Jan 27, 2010 at 3:58 PM, Lyle <[email protected]> wrote:
>
> package OrigObj;
> use ExtObj;
> my $OrigObj = {};
> bless $OrigObj, OrigObj;
>
> 1;
>
> With $OrigObj->ExtObj->new_methods; some of the new_methods will want to
> access $OrigObj.
>
> Hope that makes more sense?
Yes, I think I can see what you're doing - it's kind of a combination
of mixins and composition. You want to add some more methods to a
class, but the class is a bit unwieldy so you want to keep the extra
methods in a different package (and source file). The extra methods
are related to each other and it makes sense to group them together in
code and in how you call them.
If you *just* want to add more methods to OrigObj but put them in a
separate source file, because it's easier to manager that way, you can
do that in a couple of ways - none of which are particularly good
practice but would work.
1. In ExtObj.pm, just declare package to be OrigObj and add your extra
methods (but watch out for name clashes - make sure warnings are
enabled). This is contrary to good practice in terms of
maintainability - you expect the definition of OrigObj to be found in
OrigObj.pm only.
2. Make OrigObj inherit from ExtObj and put your extra methods in
ExtObj. This is strictly an abuse of inheritance, because (i) ExtObj
isn't a proper class and (ii) there's no model-based justification for
saying that an OrigObj is-a ExtObj.
3. Simply call methods of another package with your object. Put your
new methods in ExtObj, then call e.g. $OrigObj->ExtObj::new_methods().
Apart from looking kind of odd, this implies a violation of
encapsulation - you're passing the object to a method it doesn't have.
It also won't play well with inheritance.
Some better options:
4. Subclass OrigObj - can you make a subclass of OrigObj that
implements the extra methods, then use that instead of OrigObj?
5. Composition - rather than $OrigObj->ExtObj returning a single
shared ExtObj instance could you give each $OrigObj its own instance
of ExtObj? You mentioned the methods in ExtObj need to have access to
the $OrigObj instance, which means either a circular reference (
$OrigObj->{ ExtObj } is an instance of ExtObj, which itself holds a
reference back to $OrigObj ) or passing $OrigObj explicitly to each
method call of ExtObj. Circular refs can be OK, but it depends on your
situation.
There are plenty more ways to do it, but lets see if any of those make sense.
I didn't ask if you have more than one ExtObj class that you want to
add in at the same time, or whether ExtObj::guts is fixed or
represents one of a number of implementations of the ExtObj interface.
Alex
_______________________________________________
BristolBathPM mailing list
[email protected]
http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
