[Zope3-dev] Not really bringing the name game to a close, for now, are we?

[Tres Seaver]

Jeffrey P Shell wrote:

> This is an awful long thread to be called "Bringing the name game to a 
> close..."  :)
> 
> FWIW, I'm of the opinion that while jargon is important, let's not spend 
> too much time stumbling over it until we get a more concrete system in 
> place.  The debate could go on forever about whether a workflow 
> definition is a feature or a utility, but it would be a shame if that 
> debate got in the way of implementing them.


Agreed.


> 
> And I don't think we should get too carried away with Adapter.  Taken to 
> its literal extreme, almost all software code can be construed to fall 
> under the Adapter model.  A SQL query can be said to be adapting a large 
> set of data into a smaller set that you want to deal with.  A division 
> operator can be said to adapt two numbers into one smaller one.  Emacs 
> is adapting my wild and crazy typing into a saved file.


I would argue (if Jim hadn't already closed the discussion :)
that the intent of GoF's Adapter is much more narrow than we mean
to imply here.


> 
> There are GoF patterns besides Adapter that might bear looking at.  From 
> the inside cover under "Structural Patterns" (with page numbers for 
> those reading along at work):
> 
> Adapter(139) - Convert the interface of a class into another interface 
> clients expect.  Adapter lets classes work together that couldn't 
> otherwise because of incompatible interfaces.
> 
> Decorator(175) - Attach additional responsibilities to an object 
> dynamically.  Decorators provide a flexible alternative to subclassing 
> for extending functionality.
> 
> Sounds like 'Decorator' is closer to our 'Feature' than 'Adapter' is, 
> although both are actually viable.  I think both should be kept in mind 
> and - where necessary - separated out.


GoF's Decorator is *required* to map back to the same interface
as the "decorated" thingy;  I don't think it applies to the stuff
we have been using "Feature" for.


> 
> example - I'm working on a project management system where some tasks 
> may be billable, so I'd want to add a 'Billable' decorator to certain 
> tasks - giving them accounting functionality.  This decision comes at 
> run time, and may come into play after an object is instantiated.
> 
> If I already had billable tasks and I installed an accounting system 
> that expected the methods 'BidCost()' and 'FinalCost()' and my billable 
> tasks had been built with just a data structure of 'cost_information', 
> then I'd need an Adapter that fit the expected interface ('BidCost()' 
> and 'FinalCost()') that would get the information out of the 
> 'cost_information' data structure and return the asked value.
> 
> See also:
> 
> http://www.c2.com/cgi/wiki?AdapterPattern
> 
> http://www.c2.com/cgi/wiki?DecoratorPattern


Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com