in reply to Implementing Decorators in Perl

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

Replies are listed 'Best First'.
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.

      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();

      you can use polymorphic inheritance:

      package My_string; @ISA = qw( HTML_decorator Base64_decorator );

      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; }

      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.