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]
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
