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

Mon, 10 Dec 2001 15:28:32 -0700

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.

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.

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.

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.