Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Often Overlooked OO Programming Guidelines

by princepawn (Parson)
on Dec 29, 2003 at 20:34 UTC ( [id://317542]=note: print w/replies, xml ) Need Help??


in reply to Often Overlooked OO Programming Guidelines

Subclass to alter or add behavior.
scrottie recently said that delegation was an alternative to subclassing... I would really like some references on why delegation is a viable/better option.
That seems all fine and dandy. Now, imagine that you have that in 20 places in your code, but in the manager class, someone changes name to full_name. Because the code using the office object was forced to walk through the object heirarchy to get at the data it actually needs, you've created fragile code. Now the manager class must support a name method to be backwards compatible (and we get to start on our big ball of mud), or every reference to it must be changed -- but we've created far too many.
Not too many for :
perl -i.bak -p -e 's/manager->name/manager_fullname/';
also, you might bring up the concept of a Facade: you might not go changing the object's interface: you could keep the hold and delegate of the old to the new method.

PApp::SQL and CGI::Application rock the house

Replies are listed 'Best First'.
Re: Re: Often Overlooked OO Programming Guidelines
by Ovid (Cardinal) on Dec 29, 2003 at 21:05 UTC

    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.

      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

      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.

      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.
Re: Re: Often Overlooked OO Programming Guidelines
by iburrell (Chaplain) on Dec 30, 2003 at 01:38 UTC
    Delegation is better than inheiritance when the object doesn't want to export the full interface of the parent class. It is also useful when the object wants to change the behavior so much that it isn't a direct replacement. Also, it is helpful when the relationship needs to be dynamic, if the "parent" class is dynamic, or the referenced object needs change dynamically.

    For example, many network client classes inheirit from IO::Socket::INET. This is convienent for both internal and external use. But it fixes the clients to only use IPv4 sockets. There are other types of sockets, like IO::Socket::INET6 and IO::Socket::SSL, that could be used if the inheiritance wasn't fixed.

    Also, there is a need to change the socket but keep the same client object. Some protocols support negiotiating SSL over the existing TCP connection. The easiest way to support this is replace the reference to the IP socket with an SSL socket object.

      Hi folks,

      This is really a reply to the thread so far.

      First, nice work Ovid. I'm jealous of anyone who can write clear, simple examples - I haven't developed the skill yet.

      princepawn and iburrell - one objection I raised to subclassing rather than delegating is the breakdown of structure in the program. The best analogy I can think of is databases. Databases with one large table can't effectively be reported on - they have no structure. No relation. No parts that exist seperate from each other. You can always self-join - that is, join a table against itself, but this quickly becomes pathological. SelfJoingData at the Perl Design Patterns Repository is my attempt to flesh out this concept.

      Obviously, this fits in very strongly with the LawOfDemeter. Once you have structure, it must be navigated sanely, but if you have no structure, why even try to navigate it?

      Reporting is the database analogy. Reporting requires one-to-many and many-to-many relationships and everything required to create those - collectively known as database normalization. With object oriented code, you normally don't use the structure to report, but rather model state.One hot dog might have multiple topings. One table might order multiple hot dogs. One table might have multiple seperate checks. They might also have a pizza with multiple orders of the same topping - cheese, perhaps. If I had a nickel for every perl programmer that couldn't handle the slightist bit of one-to-many or many-to-many in code, I'd be a rich man. I've also suffered vast numbers of one-big-table Microsoft Access databases in my life.

      Database with exactly one table are a pathological case, but databases with one table and all other tables joining on only it are only a small improvement. Some reporting can be done, but only explicitly supported things. Some structure exists, but only where it is fancied for the purpose the creator had in mind. Any other reports, any other purpose, the structure is useless. Data must be gleaned dispite the structure. Or in spite of the lack of structure. Or something. This is the GodObject - one large object that knows all, sees all, controls, and only temporarily gives up control of the CPU to make method calls that are sure to return back so it can continue being in control. It is this desire to centralize control that waylays effort or interest in opening up to the wide world of event handlers, listeners, state machines, and so on and so forth - the bread and butter of the object world. You can't write a good OO program with centralized control, and you can't decentralize control as long as you build large compound objects and erase the distinction between different types of things.

      Someone in this thread used IO::Handle as an example of something to subclass - that's a good example. The rule of thumb is: subclass to create a more specific kind of something that already exists, create a new class to create a new kind of thing, and delegate to create something which knows how to do things that are defined in multiple seperate classes. IO::Handle's existing and future subclasses are specialized versions of IO::Handle: they read, write, flush, and do the things that IO::Handle does, but in special situations, and they do some related things that don't belong elsewhere. You don't get IO::Handles that work on database sockets that also know how to query the database, or if you do, hopefully they create a $dbh instance, passing it their socket, and delegate requests to that.

      I've done this rant a hundred times. Can you tell? =)

      One last bloody stab - re: Objects aren't always the way to go, absolutely. Perl Design Patterns starts off on a bender about you never know before hand that a program will grow, require additions, modifications, not to mention what it will need. You can't plan for the future, and most of the time, you shouldn't even try. I think the real art is two-fold: 1. Knowing how to start building classes, delegations, aggregations onto something procedural (or simplisticly OO) in such a way that the program grows gracefully and scales. 2. Know top down design, bottom up design, functional programming, procedural programming, relational modeling, and so on. Pick the right idiom. OO isn't for everything. People in the Java camp tend to add too much structure and thus obscure the problem and the solution they've devised, not to mention oblivion to other idioms. Using the wrong idiom is just as ineffective as using the correct idiom badly.

      A programmer who hasn't been exposed to all four of the imperative, functional, objective, and logical programming styles has one or more conceptual blindspots. It's like knowing how to boil but not fry. Programming is not a skill one develops in five easy lessons. -- Tom Christiansen in 34786.

      -scott

      jdporter - Fixed the markup error on "GodObject"

      Most of the times I prefer delegation. It is a useful technique, because it is really easy to reuse modules that way. But it depends on your programming style. I usually write small modules, which have one or two functions. I have for example a module Logging, which does exactly that: 'Logging'. I use delegation to build with them. For example I can put them in a facade, which does some more complex things.
      Inheritance I mostly use, when I want some method to be shared by all my objects.
Re: Re: Often Overlooked OO Programming Guidelines
by Steve_p (Priest) on Jan 02, 2004 at 20:33 UTC
    This has been a debate in the OO community for some time. The initial paper on this subject was "Encapsulation and Inheritance in Object-Oriented Programming Languages". The only discussion I recall seeing in a normal book on programming was Effective Java by Joshua Bloch. There are several examples of "bad" things happening in the real world. The highest profile one I remember was an upgrade of Java's Servlet classes. Many early servlet applications were created by inheriting from Sun's Java classes. Well, with the upgrade, certain portions of the class internals were changed, causing the base API to return differing values between the versions. So, to upgrade, many people had to rewrite their applications. Bloch and others argue that this can be avoided by encapsulating classes in many cases, especially if you have no control over the other class (i.e. you have the class from a vendor but not the code for it). This topic is still open to debate, and there are many cases where one is much more applicable than others.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2024-03-28 12:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found