Mixin way?

[andrea crotti]

2013/4/3 Steven D'Aprano <steve+comp.lang.python at pearwood.info>

> [snip]
>
> So, if you think of "Visitable" as a gadget that can be strapped onto
> your MyObj as a component, then composition is probably a better design.
> But if you think of "Visitable" as a mere collection of behaviour and
> state, then a mixin is probably a better design.
>
>
Well I can explain better the situation to make it more clear.

We are using CouchDb and so far it has been (sigh) a brutal manipulation of
dictionaries everywhere, with code duplication and so on.

Now I wanted to encapsulate all the entities in the DB in proper objects,
so I have a CouchObject:


class CouchObject(object) :
    """
    Encapsulate an object which has the ability to be saved to a couch
    database.
    """
    #: list of fields that get filled in automatically if not passed in
    AUTO = ['created_datetime', 'doc_type', '_id', '_rev']
    #: dictionary with some extra fields with default values if not
    # passed in the constructor the default value gets set to the attribute
    DEFAULTS = {}
    REQUIRED = []
    OPTIONAL = []
    TO_RESOLVE = []
    MIXINS = []

Where every subclass can redefine these attributes to get something
done automatically by the constructor for convenience.

Now however there is a lot of behaviour shared between them, so I want
to encapsulate it out in different places.

I think the MIXINS as I would use it is the normal composition
pattern, the only difference is that the composition is done per class
and not per object (again for lazyness reasons), right?

Probably subclassing might be fine as well, and makes it simpler, but
I don't like too much to do subclass from multiple classes...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130403/d3a41b08/attachment.html>