Path: csiph.com!usenet.pasdenom.info!news.etla.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <515c4f07$0$29966$c3e8da3$5496439d@news.astraweb.com>
References: <mailman.60.1364997899.3114.python-list@python.org> <515c4f07$0$29966$c3e8da3$5496439d@news.astraweb.com>
Date: Wed, 3 Apr 2013 17:29:02 +0100
Subject: Re: Mixin way?
From: andrea crotti <andrea.crotti.0@gmail.com>
To: "Steven D'Aprano" <steve+comp.lang.python@pearwood.info>
Content-Type: multipart/alternative; boundary=f46d044286ca1a028204d9775ac9
Cc: python-list <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.64.1365006544.3114.python-list@python.org>
Lines: 102
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:42683

--f46d044286ca1a028204d9775ac9
Content-Type: text/plain; charset=ISO-8859-1

2013/4/3 Steven D'Aprano <steve+comp.lang.python@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...

--f46d044286ca1a028204d9775ac9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2013/4/3 Steven D&#39;Aprano <span dir=3D"ltr">&lt;<a href=
=3D"mailto:steve+comp.lang.python@pearwood.info" target=3D"_blank">steve+co=
mp.lang.python@pearwood.info</a>&gt;</span><br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im" style>[snip]</div>
<br>
So, if you think of &quot;Visitable&quot; as a gadget that can be strapped =
onto<br>
your MyObj as a component, then composition is probably a better design.<br=
>
But if you think of &quot;Visitable&quot; as a mere collection of behaviour=
 and<br>
state, then a mixin is probably a better design.<br><span class=3D""><font =
color=3D"#888888"><br></font></span></blockquote><div><br></div><div>Well I=
 can explain better the situation to make it more clear.</div><div><br></di=
v>
<div>We are using CouchDb and so far it has been (sigh) a brutal manipulati=
on of dictionaries everywhere, with code duplication and so on.</div><div><=
br></div><div>Now I wanted to encapsulate all the entities in the DB in pro=
per objects, so I have a CouchObject:</div>
<div><br></div><div><br></div><div>class CouchObject(object) :</div><div>=
=A0 =A0 &quot;&quot;&quot;</div><div>=A0 =A0 Encapsulate an object which ha=
s the ability to be saved to a couch</div><div>=A0 =A0 database.</div><div>=
=A0 =A0 &quot;&quot;&quot;</div>
<div>=A0 =A0 #: list of fields that get filled in automatically if not pass=
ed in</div><div>=A0 =A0 AUTO =3D [&#39;created_datetime&#39;, &#39;doc_type=
&#39;, &#39;_id&#39;, &#39;_rev&#39;]</div><div>=A0 =A0 #: dictionary with =
some extra fields with default values if not</div>
<div>=A0 =A0 # passed in the constructor the default value gets set to the =
attribute</div><div>=A0 =A0 DEFAULTS =3D {}</div><div>=A0 =A0 REQUIRED =3D =
[]</div><div>=A0 =A0 OPTIONAL =3D []</div><div>=A0 =A0 TO_RESOLVE =3D []</d=
iv><div>=A0 =A0 MIXINS =3D []</div>
<div>=A0</div><div>Where every subclass can redefine these attributes to ge=
t something</div><div>done automatically by the constructor for convenience=
.</div><div><br></div><div>Now however there is a lot of behaviour shared b=
etween them, so I want</div>
<div>to encapsulate it out in different places.</div><div><br></div><div>I =
think the MIXINS as I would use it is the normal composition</div><div>patt=
ern, the only difference is that the composition is done per class</div>
<div>and not per object (again for lazyness reasons), right?</div><div><br>=
</div><div>Probably subclassing might be fine as well, and makes it simpler=
, but</div><div>I don&#39;t like too much to do subclass from multiple clas=
ses...=A0</div>
</div></div></div>

--f46d044286ca1a028204d9775ac9--