Implementing Decorators in Perl

dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

I've decided, because I feel like it, to roll my own Collection:: hierarchy. I'm know there's (at least) one on CPAN, but I want to roll my own, then compare to what "The Experts"(tm) have done before me. Call it a masochistically-inspired learning experience.

I'm also nearly done with reading Design Patterns. So, I'm chock-full of vim'n'vinegar and want to use as many patterns as I can as soon as I can.

So, given that a collection might want to utilize different characteristics (unique, bounded, N-dim, sorted, etc) ... I was trying to figure out the best way to structure the hierarchy.

My first idea was to create some sort of Composite, but I rationalized that away as being too complex for my baby steps.

So, I came with the idea of using Decorators. Sorta like the border on a widget. Widget::Border inherits from Widget::Generic, but isn't a standalone widget. It merely adds behavior (or decorates) the widget.

Now, I'm trying to figure out if this behavior should be class- or object-based.

Class-based would have it be done through @ISA. You, the user, would create a Collection::BoundedUniqueColl and have something like:

our @ISA = qw(
    Collection::Bounded
    Collection::Unique
    Collection::Generic
);
[download]

Then, each of these would overload add(), for example. Collection::Unique would do something like:

sub add {
    my $self = shift;
    my $thing = shift;

    return undef if $self->contains($thing);
    return $self->SUPER::add($thing);
}
[download]

And, likewise for all the other decorators.

To handle it at runtime (which is what Design Patterns suggests), each decorator would actually have an attribute being the object below (which could be the thing itself or another decorator). So, the add would look something like:

sub add {
    my $self = shift;
    my $thing = shift;

    my $collection = $self->{collection};
    return undef if $collection->contains($thing);

    return $collection->add($thing);
}
[download]

Within Collection::Decorator (which is the base for all Decorators), you'd have to have some sort of AUTOLOAD to handle every other function, sorta like:

sub AUTOLOAD {
    my $self = shift;
    my $func = our $AUTOLOAD;

    $func =~ s/.*:://;
    return $self->{collection}->$func;
}
[download]

Any thoughts?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Implementing Decorators in Perl Select or Download Code

Replies are listed 'Best First'.
Re: Implementing Decorators in Perl by Masem (Monsignor) on Jan 09, 2002 at 22:16 UTC
Just a comment: there is already a project going on that is attempted to develop the various class patterns in the Design Patters book by the Gang of Four in perl: it's at patternsinperl.com, run by Nigel Wetters. While he's pretty much just started this, he just recently posted a Decorator pattern with commentary. Note that Nigel is not claiming to be the end-all to design patterns, and does welcome suggests and references to existing perl modules that implement the design patterns, though what he appears to be doing here is to unify the design to some extent. ----------------------------------------------------- Dr. Michael K. Neylon - mneylon-pm@masemware.com \|\| "You've left the lens cap of your mind on again, Pinky" - The Brain "I can see my house from here!" It's not what you know, but knowing how to find it if you don't know that's important	[reply]
Re2: Implementing Decorators in Perl by dragonchild (Archbishop) on Jan 09, 2002 at 22:39 UTC
Hrmm... all he's doing is implementing the book's ideas. However, class-inheritance (even at run-time) is possible in Perl where it isn't in C++. The Go4 were "constrained" by a strongly-typed static-inheritance langauge. Perl is dynmically-everything. So, I guess what I really was trying to ask is should the concepts behind the Decorator pattern, when implemented Perl, be implemented with class inheritance or object composition? ------ We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.	[reply]
Re: Re2: Implementing Decorators in Perl by mstone (Deacon) on Jan 10, 2002 at 02:13 UTC
It depends on how you intend to use the classes. If you want to pass around a single object that can take multiple forms: `$e = $string->html_encoded(); $b = $string->base64();` [download] you can use polymorphic inheritance: `package My_string; @ISA = qw( HTML_decorator Base64_decorator );` [download] which is convenient when you know you'll want multiple formats, and are sure you'll know what format you want each time you use the object. OTOH, if you want to aggregate groups of objects that use different formats, you might want to use composition, and store the decorator instead of the base class: `for $i (@input_strings) { if (&is_plain ($i)) { $s = $i; } elsif (&is_html ($i)) { $s = new HTML_decorator ($i); } elsif (&is_CDATA ($i)) { $s = new Base64_decorator ($i); } push @output, $s; }` [download] Then you can use the contents of `@output` without knowing or caring what format each element happens to be. .. or not. Patterns give you ideas about what to do without telling you how to do it. If it runs, and it does what you want, it's right. Deciding what you want is up to you.	[reply] [d/l] [select]
Re (tilly) 1: Implementing Decorators in Perl by tilly (Archbishop) on Jan 09, 2002 at 23:05 UTC
Your "chock full" comment reminds me of dws' excellent node Design Patterns Considered Harmful. This is not to say that you should decide to never use a design pattern. It is to say that if you find yourself inserting patterns because you can and are excited about them, you should slap yourself, hard, and rethink whether you really need it...	[reply]