|There's more than one way to do things|
Subclassing can be handy, but it's also a problematic aspect of OO programming. Also, Perl's AUTOLOAD function can lead to horrible bugs in inheritance implementation, further confusing the issue. Subclassing is a form of composition, but delegation can solve some of the issues that composition can lead to.
As an example of problematic subclassing in Perl, take a look at this code:
Foo::_fiddle has no relation to the Bar::_fiddle method and the similarity of names is a coincidence. Unfortunately, calling the Foo::wonk method via an instance of Bar will still call the Bar::_fiddle method, even though this may not be desireable behavior. Not having clean encapsulation of private methods makes this very difficult to get around. You could try to get around it like this:
That looks better, but if the private method violates encapsulation and reaches into the object (a common practice), it might be making assumptions about what's there, even if those assumptions are not warranted.
Delegation can solve this.
Now, it doesn't matter what's in the internals of the Foo package. Inheritence doesn't bite you and everything is nice and clean.
In reply to Re: Re: Often Overlooked OO Programming Guidelines