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? _______________________________________________ gang-of-4-patterns mailing list gang-of-4-patterns@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns
