Implementing the Singleton Design Pattern
Sometimes in your applications you will have objects that by their very nature should exist at most one time and one time only; a global application object would be one example. (Indeed, Singletons occasionally get a bad rap for being glorified global variables, which developers frown on because it's more of a hassle to ensure that the state of that variable is correct everywhere.)
In IronPython, we'll store an instance of a class in a variable for reference; if that instance variable is null, we know we haven't yet created an instance of the singleton. If it's not null, we should reuse the existing reference instead of creating a new one.
Create a new file in your C:\Python folder called singleton.py, and enter the code in Listing 9-11.
Listing 9-11. Implement the Singleton Design Pattern class SpecialResource: class Singleton:
def identifyMyself(self): return id(self)
_singletonInstance = None def _init_(self):
if SpecialResource._singletonInstance is None:
SpecialResource._singletonInstance = SpecialResource.Singleton()
return getattr(self._singletonInstance, attr)
resourceOne = SpecialResource() print resourceOne.identifyMyself()
resourceTwo = SpecialResource() print resourceTwo.identifyMyself()
resourceThree = SpecialResource() print resourceThree.identifyMyself()
c:\Program Files\IronPython 2.0>ipy c:\python\singleton.py
You can see that despite having created three different objects, the Singleton class permits only one true instance to be created; as a result, the output of all three objects is identical. The specific number you see may differ from mine. The important point is that the numbers match one another in your output. If they were different, it would indicate that there was a unique ID for each object, and therefore the objects would not be Singletons. Also remember that the value displayed is not a value contained by an object itself; rather, it is the ID for the object itself.
Tip As you become more advanced as an IronPython developer, you may find your attention turning to multithreaded software development (particularly since multicore processors are becoming the norm, even on lower-end machines); the code for the Singleton implementation is not "thread safe." Although a proper discussion of multithreaded development is a topic worthy of a (very large) book by itself, it is sufficient to say that if you apply this code across multiple threads, you may encounter situations where two threads are creating instances of the Singleton at almost the same time. This condition can actually violate the design rules of the Singleton pattern and allow two different instances to be created. You can achieve a simple solution by locking code that modifies the private_singletonlnstance variable, thereby restricting access to the current thread alone; the second thread to attempt to create an instance will see the correct result. These types of threading conditions can be very difficult to diagnose because by definition they are random and not easily reproducible.
Post a comment