[Zope3-dev] Not really bringing the name game to a close, for now, are we?
Jeffrey P Shell
jeffrey@cuemedia.com
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.
See also:
http://www.c2.com/cgi/wiki?AdapterPattern
http://www.c2.com/cgi/wiki?DecoratorPattern
(apologies if this message comes through twice - Mail just yelled at me)
Jeffrey P Shell, jeffrey@cuemedia.com