Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
Perl: the Markov chain saw
 
PerlMonks  

Re: Re: Often Overlooked OO Programming Guidelines

by Ovid (Cardinal)
on Dec 29, 2003 at 21:05 UTC ( #317551=note: print w/ replies, xml ) Need Help??


in reply to Re: Often Overlooked OO Programming Guidelines
in thread Often Overlooked OO Programming Guidelines

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:

package Foo; + + sub new { my ($class, @args) = @_; bless \@args, $class } + + sub wonk { my $self = shift; $self->_fiddle(@_); } + + sub _fiddle { my $self = shift; return map { scalar reverse $_ } @_; } + + package Bar; @ISA = 'Foo'; + + sub thing { my $self = shift; $self->_fiddle(@_); } + + sub _fiddle { my ($self, @args) = @_; return map { ++$_ } @args; }

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:

# in package Foo sub wonk { my $self = shift; _fiddle($self, @_); }

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.

+ package Bar; use Foo; + + sub new { my ($class, %args) = @_; $args{_foo} = Foo->new; bless \%args, $class; } sub wonk { my $self = shift; $self->{_foo}->wonk(@_); # delegation! }

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.

Cheers,
Ovid

New address of my CGI Course.


Comment on Re: Re: Often Overlooked OO Programming Guidelines
Select or Download Code
Re: Re: Re: Often Overlooked OO Programming Guidelines
by hardburn (Abbot) on Dec 29, 2003 at 22:00 UTC

    Holding refs to subroutines seems like a perfectly good way to do private methods:

    package Foo; . . . my $fiddle = sub { my $self = shift; return map { scalar reverse $_ } @_; }; sub wonk { my $self = shift; $self->$fiddle(@_); } package Bar; sub wonk { my $self = shift; $self->$fiddle(@_); # runtime error }

    The real problem is that Perl doesn't have a good way of denoting protected methods or attributes. I don't consider litering your code with $obj->isa( . . . ) or die; to be a good way.

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

Re: Re: Re: Often Overlooked OO Programming Guidelines
by ysth (Canon) on Dec 30, 2003 at 05:54 UTC
    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:
    # in package Foo sub wonk { my $self = shift; _fiddle($self, @_); }
    I'd prefer to write that $self->Foo::_fiddle, even though it would be slower.
    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.
    Don't understand what problem/assumptions you see as problematic here. Can you elaborate?

    I don't think I would use delegation for private methods; it feels like using a wrench to unscrew a lightbulb.

      I'd prefer to write that $self->Foo::_fiddle, even though it would be slower.

      And that now means you're hardcoding the package name into the method call. Still, since you're staying within the package, this might not be a Bad Thing. I'll have to think about that.

      Don't understand what problem/assumptions [with a private method reaching into the object which ]you see as problematic here. Can you elaborate?

      This can be a problem if you're subclassing. Let's say that a Tiger is a subclass of Animal and the creator of package Tiger; decides that a blessed array reference is the way to go. With proper encapsulation, this should be irrelevant. However, when you find out that package Animal; is a blessed hashref, that's probably how you will have to implement Tiger. Once you pick how to represent a particular class, you're likely stuck with it once you subclass.

      Meanwhile, your tiger object must be uniquely identified, so you decide to create an MD5 digest for it:

      sub id { $self->{_digest} ||= $self->_create_new_digest; }

      Meanwhile, you've failed to realize that the Animal class has a private "_digest" key in the hashref to let it know if it's busy digesting food. That could be a real pain to debug, but you have to know your superclass's internals to avoid problems like this.

      Cheers,
      Ovid

      New address of my CGI Course.

Re^3: Often Overlooked OO Programming Guidelines
by polymorpheus (Novice) on Sep 06, 2012 at 16:40 UTC
    I am with you on the use of delegation. However, you could take your example one step further and use dependency injection to fully decouple the two classes.
    package Bar; sub new { my ($class, %args) = @_; bless \%args, $class; } sub wonk { my $self = shift; $self->{_foo}->wonk(@_); # delegation! } package main; use Bar; use Foo; my $bar = Bar->new(_foo => Foo->new());
    Now Bar is fully independent of Foo (coupled only by the implied "interface" which consists of the wonk() method). This also makes testing easier.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://317551]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2014-04-19 01:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (475 votes), past polls