Design Patterns discussion

["Thomas Mercer-Hursh, Ph.D." <thomas AT cintegrity.com>]

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?

--

======================================================================
 Consulting in Architecture-Driven Modernization and Transformation
----------------------------------------------------------------------
Thomas Mercer-Hursh, Ph.D.            email: 
thomas AT cintegrity.com
Computing Integrity, Inc.             voice: 510-233-5400
60 Belvedere Avenue                     fax: 510-233-5446
Point Richmond, CA 94801-4023           url: http://www.cintegrity.com
======================================================================