Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Re: Re: Re: Often Overlooked OO Programming Guidelines

by ysth (Canon)
on Dec 30, 2003 at 05:54 UTC ( #317629=note: print w/replies, xml ) Need Help??

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

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.

Replies are listed 'Best First'.
Re: Re: Re: Re: Often Overlooked OO Programming Guidelines
by Ovid (Cardinal) on Dec 30, 2003 at 07:06 UTC
    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.


    New address of my CGI Course.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://317629]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (10)
As of 2017-10-19 08:26 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (252 votes). Check out past polls.