When we add subclasses to a class hierarchy, we may also need to rearrange the statements where objects are created. To provide a flexible implementation, it is generally a good idea to centralize all of the object creation statements into a single method of class. When we extend the subclass hierarchy we can also create a relevant subclass of the centralized object creation class.

The design pattern for this kind of centralized object creator can be called a Factory. It contains the details for creating an instance of each of the various subclasses.

In the next section, Part IV, “Components, Modules and Packages”, we'll look at how to package a class hierarchy in a module. Often the classes and the factory object are bundled into one seamless module. Further, as the module evolves and improves, we need to preserve the factory which creates instances of other classes in the module. Creating a class with a factory method helps us control the evolution of a module. If we omit the Factory Method , then everyone who uses our module has to rewrite their programs when we change our class hierarchy.

Extending the Card Class Hierarchy. We'll extend the Card class hierarchy, introduced in the section called “Inheritance”. That original design had three classes: Card, FaceCard and AceCard.

While this seems complete for basic Blackjack, we may need to extend these classes. For example, if we are going to simulate a common card counting technique, we'll need to separate 2-6 from 7-9, leading to two more subclasses. Adding subclasses can easily ripple through an application, leading to numerous additional, sometimes complex changes. We would have to look for each place where the various subclasses of cards were created. The Factory design pattern, however, provides a handy solution to this problem.

An object of a class based on the Factory pattern creates instances of other classes. This saves having to place creation decisions throughout a complex program. Instead, all of the creation decision-making is centralized in the factory class.

For our card example, we can define a CardFactory that creates new instances of Card (or the appropriate subclass.)

class CardFactory( object ):
    def newCard( self, rank, suit ):
        if rank == 1:
            return Ace( rank, suit )
        elif rank in [ 11, 12, 13 ]:
            return FaceCard( rank, suit )
        else:
            return Card( rank, suit )

We can simplify our version of Deck using this factory.

class Deck( object ):
    def __init__( self ):
        factory= CardFactory()
        self.cards = [ factory.newCard( rank+1, suit )
            for suit in range(4)
                for rank in range(13) ]
    
Rest of the class is the same

Exetending the Factory. By using this kind of Factory method design pattern, we can more easily create new subclasses of Card. When we create new subclasses, we do three things:

Let's create some new subclasses of Card for card counting. These will subdivide the number cards into low, neutral and high ranges. We'll also need to subclass our existing FaceCard and Ace classes to add this new method.

class CardHi( Card ):
    """Used for 10."""
    def count( self ): return -1

class CardLo( Card ):
    """Used for 3, 4, 5, 6, 7."""
    def count( self ): return +1

class CardNeutral( Card ):
    """Used for 2, 8, 9."""
    def count( self ): return 0

class FaceCount( FaceCard ):
    """Used for J, Q and K"""
    def count( self ): return -1

class AceCount( Ace ):
    """Used for A"""
    def count( self ): return -1

A counting subclass of Hand can sum the count values of all Card instances to get the count of the deck so far.

Once we have our new subclasses, we can create a subclass of CardFactory to include these new subclasses of Card. We'll call this new class HiLoCountFactory. This new subclass will define a new version of the newCard method that creates appropriate objects.

By using default values for parameters, we can make this factory option transparent. We can design Deck to use the original CardFactory by default. We can also design Deck to accept an optional CardFactory object, which would tailor the Deck for a particular player strategy.

class Deck( object ):
    def __init__( self, factory=CardFactory() ):
        self.cards = [ factory.newCard( rank+1, suit )
            for suit in range(4)
                for rank in range(13) ]
    
Rest of the class is the same

The Overall Main Program. Now we can have main programs that look something like the following.

d1 = Deck()
d2 = Deck(HiLoCountFactory())

In this case, d1 is a Deck using the original definitions, ignoring the subclasses for card counting. The d2 Deck is built using a different factory and has cards that include a particular card counting strategy.

We can now introduce variant card-counting schemes by introducing further subclasses of Card and CardFactory. To pick a particular set of card definitions, the application creates an instance of one of the available subclasses of CardFactory. Since all subclasses have the same newCard method, the various objects are interchangeable. Any CardFactory object can be used by Deck to produce a valid deck of cards.

This evolution of a design via new subclasses is a very important technique of object-oriented programming. If we add features via subclasses, we are sure that the original definitions have not been disturbed. We can be completely confident that adding a new feature to a program will not break old features.