object inheritance

Anand anandology at gmail.com
Wed Oct 31 04:36:34 CET 2007

> No, that is an argument for multiple-inheritance, mixin classes etc. You
> know when constructing the object what behaviour you want it to have. It
> isn't an argument for changing the behaviour of an existing object
> dynamically.

Partially true. I don't want to change the behavior of an exiting
object. I know what behavior I want to have at the time of creating.
This can be achieved by creating classes dynamically by parameterizing
the base class, which I thought is ugly.

> for an example where it is useful to extend the behaviour of objects have a
> look at Zope3 interfaces and adaptors: an object can be defined to
> implement one or more interfaces, and you can associate additional
> interfaces with objects at runtime. Sometimes an object will implement an
> interface directly, but often the implementation is taken out into a
> separate 'adaptor' class. Whenever you want to use a specified interface on
> an object you simply use the interface class as a constructor on the
> object, and that might find the appropriate adapter or it might just return
> the original object if the interface is provided directly.
> e.g. seehttp://plone.org/documentation/tutorial/five-zope3-walkthrough


> Note that this is very different than the forwarding mechanism which
> started this thread: when you use an adaptor you get something which
> implements just the specified interface, you don't have to worry about
> conflicting names for methods or attributes. Also you can have a common
> interface associated with objects which have completely different adapters
> implementing that interface.

It is not a simple one-way forwarding mechanism. It is two-way.

An example:

class SimpleDB(Extend):
    def withID(self, id):
        # do query

    def withIDs(self, ids):
        return [self.withID(id) for id in ids]

class CachedDB(Extend):
    def withID(self, id):
        if id not in self.cache:
            self.cache[id] = self.super_withID(id)
        return self.cache[id]

db = CachedDB(SimpleDB())

When I call db.withIDs, it should make use of the cache, which I think
is not possible with a simple forwarding mechanism.

More information about the Python-list mailing list