2013/4/3 Steven D'Aprano <steve+comp.lang.pyt...@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...
-- http://mail.python.org/mailman/listinfo/python-list