in reply to Re: Implementing Decorators in Perl
in thread Implementing Decorators in Perl

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.

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

    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.