The code files for this chapter can be found at https://git.io/fj2U0.

Each Python class definition has an implicit superclass: object. It's a very simple class definition that does almost nothing.

We can create instances of object, but we can't do much with them, because many of the special methods simply raise exceptions.

When we define our own class, object is the superclass. The following is an example class definition that simply extends object with a new name:

>>> class X: 
>>>     pass 

The following are some interactions with this tiny class definition:

>>> X.__class__ 
<class 'type'> 
>>> X.__class__.__base__ 
<class 'object'> 

We can see that a class is an object of the class named type and that the base class for our new class is the class named object. As we look at each method, we also take a look at the default behavior...

Fundamental to the life cycle of an object are its creation, initialization, and destruction. We'll defer creation and destruction to a later chapter on more advanced special methods and focus on initialization. This will set the initial state of the object.

The superclass of all classes, object, has a default implementation of __init__() that amounts to pass. We aren't required to implement __init__(). If we don't implement it, then no instance variables will be created when the object is created. In some cases, this default behavior is acceptable.

We can add attributes to an object that's a subclass of object. Consider the following class, which requires two instance variables, but doesn't initialize them:

class Rectangle: 
    def area(self) -> float: 
        return self.length * self.width 

The Rectangle class...

We initialize an object by implementing the __init__() method. When an object is created, Python first creates an empty object and then calls the __init__() method to set the state of the new object. This method generally creates the object's instance variables and performs any other one-time processing.

The following are some example definitions of a Card class hierarchy. We'll define a Card superclass and three subclasses that are variations of the basic theme of Card. We have two instance variables that have been set directly from argument values and two variables that have been calculated using an initialization method:

from typing import Tuple

class Card:

    def __init__(self, rank: str, suit: str) -> None:
        self.suit = suit
        self.rank = rank
        self.hard, self.soft = self._points()

    def _points(self) -...

We can define classes for the suits of our cards. The suits of playing cards are an example of a type with a domain that can be exhaustively enumerated. Some other types with very small domains of values include the None type, where there's only one value, and the bool type, which has only two values.

The suit of a playing card could be thought of as an immutable object: the state should not be changed. Python has one simple formal mechanism for defining an object as immutable. We'll look at techniques to assure immutability in Chapter 4, Attribute Access, Properties, and Descriptors. While it might make sense for the attributes of a suit to be immutable, the extra effort has no tangible benefit.

The following is a class that we'll use to build four manifest constants:

from enum import Enum


class Suit(str, Enum):
    Club = &quot...

We can build a complete deck of cards via a factory function. This beats enumerating all 52 cards. In Python, there are two common approaches to factories, as follows:

• We define a function that creates objects of the required classes.
• We define a class that has methods for creating objects. This is the Factory design pattern, as described in books on object-oriented design patterns. In languages such as Java, a factory class hierarchy is required because the language doesn't support standalone functions.

In Python, a class isn't required to create an object factory, but this can be a good idea when there are related factories or factories that are complex. One of the strengths of Python is that we're not forced to use a class hierarchy when a simple function might do just as well.

As we look at the factory functions for creating Card objects, there are some alternative designs for the Card class. We might want to refactor the conversion of the rank number so that it is the responsibility of the Card class itself. This pushes the initialization down into each subclass.

This often requires some common initialization of a superclass as well as subclass-specific initialization. We need to follow the Don't Repeat Yourself (DRY) principle to keep the code from getting cloned into each of the subclasses.

This version of the Card3 class has an initializer at the superclass level that is used by each subclass, as shown in the following code snippet:

class Card3:

    def __init__(
            self, rank: str, suit: Suit, hard: int, soft: int
    ) -> None:
        self.rank = rank
        self.suit = suit
        self...

A composite object can also be called a container. We'll look at a simple composite object: a deck of individual cards. This is a basic collection. Indeed, it's so basic that we can, without too much struggle, use a simple list object as a deck.

Before designing a new class, we need to ask this question: is using a simple list object appropriate?

We can use random.shuffle() to shuffle the deck and deck.pop() to deal cards into a player's Hand.

Some programmers rush to define new classes as if using a built-in class violates some object-oriented design principle. Avoiding a new class leaves us with the following code snippet:

>>> d = [card(r + 1, s) for r in range(13) for s in iter(Suit)]
>>> random.shuffle(d)
>>> hand = [d.pop(), d.pop()]
>>> hand
[FaceCard(suit=<Suit.Club: '♣'>, rank...

The following is an example of a Blackjack Hand description that might be suitable for emulating play strategies:

class Hand:

    def __init__(self, dealer_card: Card) -> None:
        self.dealer_card: Card = dealer_card
        self.cards: List[Card] = []

    def hard_total(self) -> int:
        return sum(c.hard for c in self.cards)

    def soft_total(self) -> int:
        return sum(c.soft for c in self.cards)

    def __repr__(self) -> str:
        return f"{self.__class__.__name__} {self.dealer_card} {self.cards}"

In this example, we have a self.dealer_card instance variable based on a parameter of the __init__() method. The self.cards instance variable, however, is not based on any parameter. This kind of initialization creates an empty collection. Note that the assignment to the self.cards variable requires...

The following is an example of a degenerate class that doesn't need an __init__() method. It's a common design pattern for Strategy objects. A Strategy object is plugged into some kind of master or owner object to implement an algorithm or decision. The Strategy object often depends on data in the master object; the Strategy object may not have any data of its own. We often design strategy classes to follow the Flyweight design pattern so we can avoid internal storage in the strategy instance. All values can be provided to a Strategy object as method argument values. In some cases, a strategy object can be stateless; in this instance, it is more a collection of method functions than anything else.

In the following examples, we'll show both stateless and stateful strategy class definitions. We'll start...

As noted previously, a player has two strategies: one for betting and one for playing their hand. Each Player instance has a sequence of interactions with a larger simulation engine. We'll call the larger engine the Table class.

The Table class requires the following sequence of events by the Player instances:

1. The player must place an initial, or ante, bet based on the betting strategy.
2. The player will then receive a hand of cards.
3. If the hand is splittable, the player must decide whether to split it or not based on their game strategy. This can create additional Hand instances. In some casinos, the additional hands are also splittable.
4. For each Hand instance, the player must decide to hit, double, or stand based on their game strategy.
5. The player will then receive payouts, and they must update their betting strategy based on their wins and...

We may have objects that are created from a variety of sources. For example, we might need to clone an object as part of creating a memento, or freeze an object so that it can be used as the key of a dictionary or placed into a set; this is the idea behind the set and frozenset built-in classes.

We'll look at two design patterns that offer multiple ways to build an object. One design pattern uses a complex __init__() method with multiple strategies for initialization. This leads to designing the __init__() method with a number of optional parameters. The other common design pattern involves creating multiple static or class-level methods, each with a distinct definition.

Defining an overloaded __init__() method can be confusing to mypy, because the parameters may have distinct value types. This is solved by using the @overload decorator...

We'll take a look at a few other, more advanced __init__() techniques. These aren't quite so universally useful as the techniques in the previous sections.

The following is a definition for the Player class that uses two Strategy objects and a table object. This shows an unpleasant-looking __init__() method:

class Player:

    def __init__(
        self, 
        table: Table, 
        bet_strategy: BettingStrategy, 
        game_strategy: GameStrategy
    ) -> None:
        self.bet_strategy = bet_strategy
        self.game_strategy = game_strategy
        self.table = table

    def game(self):
        self.table.place_bet(self.bet_strategy.bet())
        self.hand = self.table.get_hand()
        if self.table.can_insure(self.hand):
            if self.game_strategy.insurance(self.hand):
                self.table.insure(self.bet_strategy.bet())
   ...

In this chapter, we have reviewed the various design alternatives of the __init__() method. The __init__() method is how objects are created, and it sets the initial state of an object.

We've looked at how all Python objects are subclasses of a common parent, the object class, and how the default __init__() method for the object class works. This consideration leads to two design strategies for placement of the __init__() method:

• We can define a common __init__() method for all subclasses of a hierarchy. This can lead to using a factory function, separate from the __init__() method, to help initialize objects correctly.
• We can push the __init__() method into each individual subclass of a complex hierarchy, and how this changes the design of classes.

After looking at building individual objects, we looked at how we can ...