mailRe: The singleton design pattern for the old 'self.relax.data' data structure.


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on March 09, 2007 - 14:33:
On 3/9/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:
On Fri, 2007-03-09 at 17:38 +1100, Edward d'Auvergne wrote:
> Looking back at the example you gave:
>
> class Data:
>    ...
> Data = Data()
>
> in the data module, then everywhere else:
>
> from data import Data as relax_data
>
> This is very similar to Gary's suggestion and is conceptually the same
> as the code in the repository.  I just realised that the example is in
> fact a singleton design pattern.  The Data class is being overwritten
> by the single Data class instance reference.  Then every time Data is
> imported, a reference is given by the module rather than the class
> which no longer exists in the module namespace.  Although the
> implementations are slightly different, Gary's singleton suggestion
> (https://mail.gna.org/public/relax-devel/2007-03/msg00020.html,
> Message-id: <45EFCABC.9040905@xxxxxxxxxxxxxxx>), your suggestion Chris
> (https://mail.gna.org/public/relax-devel/2007-03/msg00013.html,
> Message-id: <1173263918.8066.238.camel@mrspell>), and mine
> (https://mail.gna.org/public/relax-devel/2007-03/msg00012.html,
> Message-id: <7f080ed10703070006s309a1e1do38e621f48d8f6d9e@xxxxxxxxxxxxxx>)
> are formally identical, each returns the reference to the single Data
> instance.

I would argue that they are functionally identical, but formally quite
different. Quite apart from the differences in terms of __init__ that I
mentioned earlier, it is usefull to look at the differences in terms of
what a user will see if they examine a client module. In the current
implimentation, the user will see

relax_data = Data()

and wrongly assume that the client module has created its own instance
of Data, because that is what the code says. As they examine the rest of
the code, they are likely to be at a complete loss as to how that
instance communicates with the rest of the program, because each module
appears to create an independent instance. In my proposal, the user will
see

from data import Data as relax_data

and realise that each client module imports one and the same data object
every time.

It is this clarity of code and simplicty of concept that I am trying to
argue for here, not any functional difference.

Actually, the 'from data import Data as relax_data' is potentially more confusing as you wouldn't normally expect a reference to an instantiated class to be returned when importing (instead of the class itself). Either it would have to be documented in the relax manual or the user reads the code. With the standard class import if someone is familiar class imports they won't have a problem - otherwise the user could read the object's docstring. Anyway, for the user to understand how to access the relax data storage object they must have either have read about it in the manual or seen it in a script. Either way, all three implementations and their import and subsequent class instantiation (Edward), instance reference renaming (Chris), or function calling (Gary) are going to be equally easily learnt (if so desired by the adventurous power user). Gary, do you have an opinion on the subject?

Cheers,

Edward



Related Messages


Powered by MHonArc, Updated Fri Mar 09 19:20:29 2007