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).


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]

Zope3-users mailing list

Reply via email to