[Zope3-Users] To Subclass, or to Adapt?
dominik.huber at perse.ch
Fri Aug 12 10:59:41 EDT 2005
Stephan Richter wrote:
>On Friday 12 August 2005 04:20, Dominik Huber wrote:
>>Your question points out the general problematic the implementation
>>decision between classification and composition. Zope 3 has the power to
>>reduce an object to its *pure* identity and implement all further
>>functionality by adapters and annotated objects (see
>>zope.app.annotation). This possibility allows you to build objects
>>heavily throu composition. In extreme case the classification aspect is
>>*only* used to determine the adapter lookups and other registration
>>Therefore it will be usefull to use interfaces to build the above
>>classification, but - and that's very important - that does not mean
>>that you transfer this classification directly to your deeper
>>implementation (classes), but you could use *pure* marker interfaces for
>>that classification purpose too. Those pure marker interfaces could mark
>>instances of a generic object implementation .
>Right, I know you follow this approach with Tiks and it is probably a good
>approach for CMSs, where everything depends on the behavior in the system,
CMS was never the core target. The indent is to offer easily orthoganl
functionality (for example cms-functionality) within specific business
models and its content components. (It's not my purpose to force
somebody on my approach, but I wanted to sketch an additional
possibility/interpretation of the new component architecture.)
>but for regular applications its bogus. I really expect my core objects to
>have a core functionality.
I would never recommend tiks for regular applications** too, but it's
not bogus for regular applications doing so, it's just an
overhead/overdesign. IMO it's like MVC instead of decoupling views from
models, you are going to decouple models (logic) from implementations.
Sometimes both is a yagni.
In the past (zope 2) lot of core-functionality (for example cms's) were
forced to behave like specific business objects/applications. But all
the efforts could never transform the underlying implementation and
their core-functionality satisfactorily as soon as a certain business
model was not a subset of the underlying functionality. Now we have the
great component architecture and it is fairly easy to design cms and
other functionalities/applications more orthogonaly. So we can think
about business objects that provides a superset of a few, orthogonal
(core-)functionalities/applications. It would make sense to find a
passable way to handle/monitor all this orthogonal functionalities
within a single business-object instance. Such an instance is a
compostions of objects that are supporting this orthagonal
functionalities/applications. IMO in those cases it is pointless to
argue about which functionality of those delegatees will be the most
*core* and implement that within its class, it's just arbitrariness.
**IMO a regular application has a pretty stable business model, but
there are a lot of unorthodox, evolving beasts in that respect. Those
applications are basing on switching, expanding or growing business
models. Those unorthodox applications has to focus most of the time to
more general core functionalities such as 'to be cost-effective and
handle the logical changes over the application's life cyle for nothing'
More information about the Zope3-users