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

[Dominik Huber]

Hi James
A few other thoughts...

James Allwyn wrote:

>I would appreciate any guidance on what the
>recommended Zope3-ish way of handling this would be. I
>feel the options are either to create a generic
>IProperty object, and subclass it to IHouse,
>ICateredHall, ISelfCateredHall, IHomeStay, or
>whatever, which each add extra features or
>constraints; or to go down some sort of adapter route.
>  
>
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].

You could use a generic Property instance that is directly 
classified/typed by a marker (see zope.interface.directlyProvides), for 
example ICateredHall. You can add further funcitonality  by adapters 
registered to ICanteredHall and you could 'emulate' inheritance 
registering general adapters to super-marker-interfaces such as 
IProperty and dedicated adapters to the sub-marker-interfaces like 
ICateredHall.

To follow this pattern it is nessesary to simplify the composition 
handling of the generic Property in such a way that it becomes easy to 
implement new adapters and the corresponding delegated objects 
(composite). The IProperty interface should reflect the API to 
handle/access the stuff like washing machine, mircowave etc. (compositon 
of delegated objects). In other words a simple attribution of the 
delegated objects which allows validation and should be fairly 
extentable [2].

>Regarding the Adapters route, in his book Phillip
>gives an analogy of Interfaces as a contract that an
>object uses to promise its functionality. If an
>Interface promises that an object will have a given
>method, does it have to provide it directly, or can it
>use an adapter to provide it?
>  
>
If an object promises it provides an interface it has to do so directly, but *it can also promises an adapter to an interface* (for example zope.app.annotation.IAttributeAnnotable promisses an IAnnotations adapter).

Regards,
Dominik

PS: We try to follow such a generic approach within tiks. Our 
implementation abstraction
unit is IComponent where such a component could be an ISystem or an 
IElement (Nested v.. atomic). Each IComponent represents a *logical* 
information cluster or system [3]. A concrete instance consists of a 
generic container which is marked by a domain-specific type-marker. The 
type-marker determines the hierarchical specific attribution-namespace 
called delegations [4].  Alll delegated composites live there and can be 
accessed by a general IDelegations-API .Result: Programming gets pretty 
modular and extendable, but the abstraction and generalisation hurts the 
brain and slows down the understanding/communication ;)

[1] Example implementation which accounts this problem: tiks.typing 
[svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/typing] there we follow 
such an approach. It a little framework to use generic implementation 
that get classified or typed by an marker interface only

[2] Example implementation which accounts this problem: tiks.attribution 
[svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/attribution] there we 
provide hierarchical namespaces (Attribution). A namespace  is 
determined by a attribution schema which allows to map dotted-names to 
an interface that should be required for an object referenced by the 
given name.

[3] tiks.system [svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/system]

[4] tiks.delegation 
[svn://svn.tiks.org/repos/Tiks/trunk/src/tiks/delegation]