[Zope3-dev] Chapter 1 Step 6 now available

[Steve Alexander]

Tres Seaver wrote:
>
> It is *almost* Decorator;  the key distinction is that the additional
> behavior of the Decorator is an extension / modification of one or
> more methods of the interface being "decorated":  the canonical example
> is to extend the 'draw' method of a window by adding a border.

A decorator can add further methods. See the BorderDecorator in page 176 
of the GOF book, which adds the method DrawBorder().

"""
Decorator subclasses are free to add operations for specific 
functionality. For example, ScrollDecorator's ScrollTo operation lets 
other objects scroll the interface *if* they know there happens to be a 
ScrollDecorator object in the interface. The important aspect of this 
pattern is that it lets decorators appear anywhere a VisualComponent 
can. That way, clients generally can't tell the difference between a 
decorated component and an undecorated one, and so they don't depend at 
all on the decoration.
"""
GOF, page 176-177

That very accurately describes what my Decorator class does. The 
interface it declares, via __implements__, is exactly the same as the 
component it is decorating. However, it adds certain operations that 
views can use *if* they know about them.

So, I still maintain that my use of the term "Decorator" is valid.


> In fact, the aquisition-based composition of behaviors here is perhaps
> closer to the Gof Chain-of-Responsibility pattern in its guts, where
> the chained method is '__getattr__'.

Sure, it is implemented as a Chain of Responsibility. However, if you 
ask what the Decorator object implements, it will give you the same 
answer as the component it is decorating would.

So, it is a generic Decorator that decorates according to a Chain of 
Responsibility.

> Perhaps we need to write up a GoF-style pattern, 'Acquisition', and
> just refer to that. :)

I'm not sure that Acquisition says much about interfaces.

--
Steve Alexander