How to Think Like a Computer Scientist: Learning with Python 2nd Edition/Inheritance

= Inheritance = The language feature most often associated with object-oriented programming is inheritance. Inheritance is the ability to define a new class that is a modified version of an existing class.

The primary advantage of this feature is that you can add new methods to a class without modifying the existing class. It is called inheritance because the new class inherits all of the methods of the existing class. Extending this metaphor, the existing class is sometimes called the parent class. The new class may be called the child class or sometimes subclass.

Inheritance is a powerful feature. Some programs that would be complicated without inheritance can be written concisely and simply with it. Also, inheritance can facilitate code reuse, since you can customize the behavior of parent classes without having to modify them. In some cases, the inheritance structure reflects the natural structure of the problem, which makes the program easier to understand.

On the other hand, inheritance can make programs difficult to read. When a method is invoked, it is sometimes not clear where to find its definition. The relevant code may be scattered among several modules. Also, many of the things that can be done using inheritance can be done as elegantly (or more so) without it. If the natural structure of the problem does not lend itself to inheritance, this style of programming can do more harm than good.

In this chapter we will demonstrate the use of inheritance as part of a program that plays the card game Old Maid. One of our goals is to write code that could be reused to implement other card games.

A hand of cards
For almost any card game, we need to represent a hand of cards. A hand is similar to a deck, of course. Both are made up of a set of cards, and both require operations like adding and removing cards. Also, we might like the ability to shuffle both decks and hands.

A hand is also different from a deck. Depending on the game being played, we might want to perform some operations on hands that don't make sense for a deck. For example, in poker we might classify a hand (straight, flush, etc.) or compare it with another hand. In bridge, we might want to compute a score for a hand in order to make a bid.

This situation suggests the use of inheritance. If Hand is a subclass of Deck, it will have all the methods of Deck, and new methods can be added.

In the class definition, the name of the parent class appears in parentheses:

This statement indicates that the new Hand class inherits from the existing Deck class.

The Hand constructor initializes the attributes for the hand, which are name and cards. The string <tt>name</tt> identifies this hand, probably by the name of the player that holds it. The name is an optional parameter with the empty string as a default value. <tt>cards</tt> is the list of cards in the hand, initialized to the empty list:

For just about any card game, it is necessary to add and remove cards from the deck. Removing cards is already taken care of, since <tt>Hand</tt> inherits <tt>remove</tt> from <tt>Deck</tt>. But we have to write <tt>add</tt>:

Again, the ellipsis indicates that we have omitted other methods. The list <tt>append</tt> method adds the new card to the end of the list of cards.

Dealing cards
Now that we have a <tt>Hand</tt> class, we want to deal cards from the <tt>Deck</tt> into hands. It is not immediately obvious whether this method should go in the <tt>Hand</tt> class or in the <tt>Deck</tt> class, but since it operates on a single deck and (possibly) several hands, it is more natural to put it in <tt>Deck</tt>.

<tt>deal</tt> should be fairly general, since different games will have different requirements. We may want to deal out the entire deck at once or add one card to each hand.

<tt>deal</tt> takes two parameters, a list (or tuple) of hands and the total number of cards to deal. If there are not enough cards in the deck, the method deals out all of the cards and stops:

The second parameter, <tt>num_cards</tt>, is optional; the default is a large number, which effectively means that all of the cards in the deck will get dealt.

The loop variable <tt>i</tt> goes from 0 to <tt>nCards-1</tt>. Each time through the loop, a card is removed from the deck using the list method <tt>pop</tt>, which removes and returns the last item in the list.

The modulus operator ( <tt>%</tt>) allows us to deal cards in a round robin (one card at a time to each hand). When <tt>i</tt> is equal to the number of hands in the list, the expression <tt>i % nHands</tt> wraps around to the beginning of the list (index 0).

Printing a Hand
To print the contents of a hand, we can take advantage of the <tt>printDeck</tt> and <tt>__str__</tt> methods inherited from <tt>Deck</tt>. For example:

It's not a great hand, but it has the makings of a straight flush.

Although it is convenient to inherit the existing methods, there is additional information in a <tt>Hand</tt> object we might want to include when we print one. To do that, we can provide a <tt>__str__</tt> method in the <tt>Hand</tt> class that overrides the one in the <tt>Deck</tt> class:

Initially, <tt>s</tt> is a string that identifies the hand. If the hand is empty, the program appends the words <tt>is empty</tt> and returns <tt>s</tt>.

Otherwise, the program appends the word <tt>contains</tt> and the string representation of the <tt>Deck</tt>, computed by invoking the <tt>__str__</tt> method in the <tt>Deck</tt> class on <tt>self</tt>.

It may seem odd to send <tt>self</tt>, which refers to the current <tt>Hand</tt>, to a <tt>Deck</tt> method, until you remember that a <tt>Hand</tt> is a kind of <tt>Deck</tt>. <tt>Hand</tt> objects can do everything <tt>Deck</tt> objects can, so it is legal to send a <tt>Hand</tt> to a <tt>Deck</tt> method.

In general, it is always legal to use an instance of a subclass in place of an instance of a parent class.

The <tt>CardGame</tt> class
The <tt>CardGame</tt> class takes care of some basic chores common to all games, such as creating the deck and shuffling it:

This is the first case we have seen where the initialization method performs a significant computation, beyond initializing attributes.

To implement specific games, we can inherit from <tt>CardGame</tt> and add features for the new game. As an example, we'll write a simulation of Old Maid.

The object of Old Maid is to get rid of cards in your hand. You do this by matching cards by rank and color. For example, the 4 of Clubs matches the 4 of Spades since both suits are black. The Jack of Hearts matches the Jack of Diamonds since both are red.

To begin the game, the Queen of Clubs is removed from the deck so that the Queen of Spades has no match. The fifty-one remaining cards are dealt to the players in a round robin. After the deal, all players match and discard as many cards as possible.

When no more matches can be made, play begins. In turn, each player picks a card (without looking) from the closest neighbor to the left who still has cards. If the chosen card matches a card in the player's hand, the pair is removed. Otherwise, the card is added to the player's hand. Eventually all possible matches are made, leaving only the Queen of Spades in the loser's hand.

In our computer simulation of the game, the computer plays all hands. Unfortunately, some nuances of the real game are lost. In a real game, the player with the Old Maid goes to some effort to get their neighbor to pick that card, by displaying it a little more prominently, or perhaps failing to display it more prominently, or even failing to fail to display that card more prominently. The computer simply picks a neighbor's card at random.

<tt>OldMaidHand</tt> class
A hand for playing Old Maid requires some abilities beyond the general abilities of a <tt>Hand</tt>. We will define a new class, <tt>OldMaidHand</tt>, that inherits from <tt>Hand</tt> and provides an additional method called <tt>remove_matches</tt>:

We start by making a copy of the list of cards, so that we can traverse the copy while removing cards from the original. Since <tt>self.cards</tt> is modified in the loop, we don't want to use it to control the traversal. Python can get quite confused if it is traversing a list that is changing!

For each card in the hand, we figure out what the matching card is and go looking for it. The match card has the same rank and the other suit of the same color. The expression <tt>3 - card.suit</tt> turns a Club (suit 0) into a Spade (suit 3) and a Diamond (suit 1) into a Heart (suit 2). You should satisfy yourself that the opposite operations also work. If the match card is also in the hand, both cards are removed.

The following example demonstrates how to use <tt>remove_matches</tt>:

Notice that there is no <tt>__init__</tt> method for the <tt>OldMaidHand</tt> class. We inherit it from <tt>Hand</tt>.

<tt>OldMaidGame</tt> class
Now we can turn our attention to the game itself. <tt>OldMaidGame</tt> is a subclass of <tt>CardGame</tt> with a new method called <tt>play</tt> that takes a list of players as a parameter.

Since <tt>__init__</tt> is inherited from <tt>CardGame</tt>, a new <tt>OldMaidGame</tt> object contains a new shuffled deck:

The writing of <tt>printHands</tt> is left as an exercise.

Some of the steps of the game have been separated into methods. <tt>remove_all_matches</tt> traverses the list of hands and invokes <tt>remove_matches</tt> on each:

<tt>count</tt> is an accumulator that adds up the number of matches in each hand and returns the total.

When the total number of matches reaches twenty-five, fifty cards have been removed from the hands, which means that only one card is left and the game is over.

The variable <tt>turn</tt> keeps track of which player's turn it is. It starts at 0 and increases by one each time; when it reaches <tt>numHands</tt>, the modulus operator wraps it back around to 0.

The method <tt>playOneTurn</tt> takes a parameter that indicates whose turn it is. The return value is the number of matches made during this turn:

If a player's hand is empty, that player is out of the game, so he or she does nothing and returns 0.

Otherwise, a turn consists of finding the first player on the left that has cards, taking one card from the neighbor, and checking for matches. Before returning, the cards in the hand are shuffled so that the next player's choice is random.

The method <tt>find_neighbor</tt> starts with the player to the immediate left and continues around the circle until it finds a player that still has cards:

If <tt>find_neighbor</tt> ever went all the way around the circle without finding cards, it would return <tt>None</tt> and cause an error elsewhere in the program. Fortunately, we can prove that that will never happen (as long as the end of the game is detected correctly).

We have omitted the <tt>print_hands</tt> method. You can write that one yourself.

The following output is from a truncated form of the game where only the top fifteen cards (tens and higher) were dealt to three players. With this small deck, play stops after seven matches instead of twenty-five.

So Jeff loses.

Exercises

 * 1) Add a method, <tt>print_hands</tt>, to the <tt>OldMaidGame</tt> class which traverses <tt>self.hands</tt> and prints each hand.