[Zope3-Users] To Subclass, or to Adapt?

[Dominik Huber]

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
>>aspects.
>>
>>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 [1].
>>    
>>
>
>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.

Regards,
Dominik

**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' 
etc. ;)