Design Patterns discussion

[David Rosenstrauch <darose AT darose.net>]

Sorry for the late response.

My understanding of Decorator is that its intent is that it's a wrapper 
that you use to add new functionality to a class/object that doesn't 
already have it.  Projecting forward from that, then, you could add 
multiple pieces of functionality onto an object by repeatedly wrapping 
it in decorators - resulting in a chain of decorators, with the 
decorated object at the end.

Quintessential example of this would be, say, the InputStream and 
OutputStream families of I/O objects in Java.  You take any "vanilla" 
stream object (e.g., that writes to a file, a socket, etc.) and then add 
functionality onto it by wrapping it in decorator streams - e.g., 
BufferedOutputStream, PrintStream, etc.

More info at Wikipedia (http://en.wikipedia.org/wiki/Decorator_pattern), 
though admittedly that's not necessarily a canonical source.

Not quite sure whose side of your argument I'm falling out on here 
(yours maybe?) but I hope the additional data point is helpful to you guys.

DR

On 02/17/2010 03:29 PM, Thomas Mercer-Hursh, Ph.D. wrote:
> I'm having a bit of a debate with a colleague about the GoF Decorator
> pattern and I'm wondering what this group thinks.
>
> His position is that the Intent of Decorator specifically states that
> Decorator provides a "flexible alternative to subclassing for extending
> functionality" and that the balance of the pattern description
> reinforces this statement.  He is therefore inclined to use Decorator
> routinely as a means of creating subtypes of a base entity, citing the
> flexibility this provides and the way that it avoids the "crosstab"
> problem which can occur when there are multiple classifications that can
> all apply at the same time to the same base entity.
>
> My read of GoF is that Decorator was specifically intended for dynamic
> additions of functionality particularly in cases which functionality is
> context dependent and/or where the functionality in question is not
> systematically applied to all instances.  E.g., any particular Order
> must be one or the other of an InternalOrder or an ExternalOrder, so I
> would not use Decorator to make that distinction because all Orders are
> one or the other.  But, some Windows have scroll bars and some don't and
> the category No Scroll Bars has no specific functionality associated
> with it, so that is a good example of a context in which to use Decorator.
>
> To me, the preferred approach for dealing with a potential "crosstab"
> generalization problem is to use a combination of Generalization and
> Delegation, i.e., by identifying cohesive spheres of responsibility
> which can be segregated into their own delegate generalization
> hierarchy, one removes one of the possible "dimensions" of the
> crosstab.  Do that enough and one reduces all generalization hierarchies
> to simple ones.
>
> I.e., I would do what decomposition I could do with Generalization and
> Delegation and only resort to Decorator for what was "left over" because
> it didn't fall into the category of the kinds of breakdowns for which
> systematic decomposition was appropriate.
>
> What does this group think?