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 Gary S. Thompson on March 08, 2007 - 09:35:
Chris MacRaild wrote:

On Wed, 2007-03-07 at 19:06 +1100, Edward d'Auvergne wrote:



Hi,

After careful thought about design patterns, I've decided to try to
use the singleton pattern for the old 'self.relax.data' data
structure.  See http://en.wikipedia.org/wiki/Singleton_pattern for
more information about this design pattern.  I'll try to use the
second simple example under the heading 'Python Borg pattern'.  The
benefit of this pattern is that each module can use the code:

from data import Data
relax_data = Data()

As Data will be a singleton if two modules used by relax instantiate
the Data class then the global 'relax_data' in both modules will be
the same instance. Therefore if a method from the
'special_fns.model_free' module modifies the data structure, all the
other relax modules using the singleton will see the changes. The
benefit of this pattern is that the data structure is similar in
concept to a global variable but only modules utilising it will have
it in one of their namespaces. Also 'self.relax.data' will not need
to be passed around inside the program, simplifying the code. What do
you think of the idea?



One issue here, identified on the wikipedia page, is that __init__() is called for each call of Singleton(). Therefore all of the standard __init__() stuff - inialising variables and empty containers - will happen every time the Singleton instance is sought. This is clearly not what we want. Ofcourse there are many ways around that by cleverly hiding the initialisation stuff, but its starting to look like a complex solution to what should be a simple problem.

Something like:

class Data:
   ...
Data = Data()

in the data module, then everywhere else:

from data import Data as relax_data


By rebinding the name 'Data' with an instance of the class, we effectively prevent accidental creation of additional instances, and the import makes that instance availible wherever we need it.

Chris



I agree

another alternative would be a more classic singleton such as


class _Singleton(object):

   def __init__(self):
       # just for the sake of information
       self.instance = "Instance at %d" % self.__hash__()


_singleton = _Singleton()

def Singleton(): return _singleton

=====

from singleton import Singleton
s1 = Singleton()
s2 = Singleton()
s1.instance
'Instance at -1226695220'
s2.instance
'Instance at -1226695220'
s1 == s2
True

which is from the discussion on http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52558



Cheers,

Edward


P.S. Another idea would be to create the variable 'relax_data.current_run'. The 'relax_data' singleton structure will be a dictionary type as proposed in the redesign discussions, hence you would have say 'relax_data['m5']' being another object containing all the model-free model m5 data, but the variable could be part of the singleton data structure. The data object of the current run could then be accessed as 'data = relax_data[relax_data.current_run]'. This is probably an anti-pattern so please feel free to suggest better ideas.





_______________________________________________
relax (http://nmr-relax.com)

This is the relax-devel mailing list
relax-devel@xxxxxxx

To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel

.





--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK             Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx                   Fax  +44-113-2331407
-------------------------------------------------------------------





Related Messages


Powered by MHonArc, Updated Fri Mar 09 08:40:25 2007