To implement the Singleton design pattern for the entire state class hierarchy, we must add a static variable, theInstance, initially null, to each individual subclass of Player1326State. Additionally, we have to add a getInstance method to each subclass. Finally, we can make the constructor protected in the superclass to prevent any other class from using it via the new operator.

Note that we can't inherit a single superclass definition of theInstance variable or getInstance method. Being static, these would be shared by all objects of all four subclasses. We would only have a single Player1326State object, and it would be the initially constructed object. Consequently, we need to have a distinct instance variable and method in each subclass, so that an instance of each distinct subclass gets created.

This aspect of this class hierarchy has to be included by a tedious cut-and-paste process. It might be nice to specify that this piece of programming is copied out of a template into each class, assuring consistent implementation of the Singleton design pattern. There are a few automated approaches to this, including tools for aspect-oriented programming and literate programming. Both of these are areas for further investigation, well outside the scope of this book.

The Player1326 constructor would be changed to use the getInstance method of Player1326NoWins to create the initial state. We have to remove the creation a new instance via new Player1326NoWins() and replace this with Player1326NoWins.getInstance().

Each state's nextWon and nextLost methods would have to use the getInstance method to get the next state instance. By removing all of the individual new operations, we assure that objects are only made available through getInstance, controlling the number of instances actually created.

 Player1326 {
  static Player1326State theInstance = null;
  static Player1326State getInstance();
}

We note that the compile-time binding in Java forces us to repeat these two static elements in each class. There is some administrative overhead in assuring that this aspect of the Singleton pattern is repeated in each subclass. In Python, however, the late binding makes this slightly simpler.

This class can be sped up by using the Singleton design pattern for the entire state class hierarchy. In Python, we have two choices for dealing with the various singleton instances. The most common solution is to create module-level variables at import time; Python assures that each module is only important once. A second solution is to implement a Java-like singleton design in the classes.

Because of the deferred binding in Python, we can easily have each class contain references module-level variables that won't be created until after the class is defined. The variables don't exist when the class is defined, but they will exist when the object methods are actually executed. Each class can then expect a module-level variable with a name like theNoWinsState. These four variables are created by the module after the definitions of the classes.

Module Implementation of the Singleton Pattern in Python

The module-level instance variable implementation would look like the following.

Example 17.2. Python player Module

class Player1326State:
    def __init__( self ):
        pass
    other superclass definitions

class Player1326NoWins( Player1326State ):
    def __init__( self ):
        pass
    def nextStateWon( self ):
        return player.theOneWinState 
    the rest of the no wins class definition

Player1326OneWins( Player1326State ):
    the rest of the one win class definition

theNoWinsState= Player1326NoWins()
theOneWinState= Player1326OneWin() 

	A reference to a module-level variable, player.theOneWinState, that will be created later on during the module import. The module name qualification is required to indicate the context in which the variable was created.
	This creates a module-level variable, theOneWinState, used by the class declarations.

The Java-style declaration means that we have a theInstance variable which contains the one-and-only instance for this class. Note that we have two choices for handling the object creation. We can override the __new__ method, or we can provide a getInstance method. We'll focus on the getInstance method because it's most like Java.

For programmers new to Python, there are two small syntax changes that make a variable or method part of the class and not part of each individual instance. First, instance variables must be created by __init__ and qualified with the instance name (usually self). If, instead, we simply place a variable in the class definition, this variable belongs to the class, and therefore it belongs to every instance of the class. Second, if we call a method using an object name, the method is called with that given instance as the value for self. If, instead, we call a method using the class name, the method is called for the class as a whole.

Python Singleton Class

The Java-like singleton has an implementation would look like the following.

Example 17.3. Python Singleton With Class Variables

class Player1326State:
    def __init__( self ):
        the rest of the superclass definition

class Player1326NoWins( Player1326State ):
    theInstance= None 
    def __init__( self ):
        the rest of the class definition
    def getInstance( self ): 
        if not self.theInstance:
            self.theInstance= Player1326NoWins()
        return self.theInstance
    def nextStateWon( self ):
        return Player1326OneWins.getInstance() 
        the rest of the no wins class definition

Player1326OneWins( Player1326State ):
    theInstance= None
    the rest of the one win class definition

	The theInstance variable is part of the class, and therefore common among all instances. We can refer to it either as self.theInstance or as Player1326NoWins.theInstance. Each subclass must have this declaration.
	If necessary, create an instance of this class. Return the one-and-only instance of this class. Because of Python's late binding, this does not have to be repeated in each subclass.
	A reference to the getInstance in the target class that returns the one-and-only instance of the Player1326OneWins. class

The use of module-level singletons is a common idiom in Python applications. It suffers from the limitation of making it difficult to define subclasses properly. This limitation arises because an important feature of the class are the module-level variables, which are created separately from the class. The following scenario should clarify the situations under which module variables are a problem.

Consider the situation where we have the Player1326 packaged in a single module file that includes the Player1326 class and the Player1326State classes. This module is imported into the main application to provide the definition of the player strategy. We have a variation on this strategy, so we need to extend the class definitions with subclasses to implement this variation. We have two choices for packaging this extension.

• We update the module file to add additional classes and module variables. While simple, we may elect to leave this file untouched because of a license agreement.
• Our application imports the original module and derives new subclasses from it. We will also have to create global variables in our application to define singleton instances of our new states. Assuring that the state classes have singleton instances is the kind of complexity that makes maintenance and enhancement expensive.
• We create a module file that imports the original module file, and adds our extensions to it. We have to be careful with our import so that this two-part import is transparent to client modules and classes. Our derived module file must have the necessary module variables defining singleton instances of our new states.

We feel that the point of OO software is to promote reuse, extension and flexibility. We find that module-level variables are a potentially obscure complexity. The alternative is to make each Singleton class self-contained.