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
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
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.
| [reply] [Watch: Dir/Any] [d/l] |
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.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] [d/l] |
|
|