Designing Card Game Classes

Imagine you already have a class that does most of what your program needs. Perhaps it stores a collection of cards and knows how to add a card to that collection. Now your new project needs something that is nearly the same but differs in a few specific ways. You have three options. You could rewrite the whole class, which is wasteful because most of the work is already done. You could copy the code into a new file, which creates two versions that must be maintained separately and can drift apart over time. Or you could use the third option that object-oriented languages offer: build the new class on top of the old one and write only the parts that are different.

This article follows that idea through a card game. As you read, pay attention to which part of the program is inherited without being rewritten and which part is new. Those two parts are where most errors in subclass code come from, so learning to tell them apart is the real skill here.

The general form of a subclass header has three parts in a fixed order. The name of the new class comes first, followed by the keyword extends and then the name of the existing class. The braces that follow hold the changes and additions. The ellipsis in the general pattern stands for code you would write yourself, not code you copy literally.

Read the header from left to right as a sentence: BlackjackHand is a class that extends Hand. The name on the left is the new class, the name after extends is the class it builds on, and the braces are where you write the differences. Nothing inside the braces needs to repeat what Hand already provides.

The program aims to play Blackjack and can reuse the Card, Hand, and Deck classes already developed. A generic hand of cards, however, is not quite the same as a Blackjack hand. A Blackjack hand must be able to report its value according to the rules of the game, while a generic hand has no reason to know those rules. That makes the Blackjack hand a natural candidate for a subclass of Hand. It keeps everything a Hand already does and adds the one capability the game requires.

The direction of the relationship matters. The arrow in a class diagram runs from the subclass to the class it extends, which means BlackjackHand depends on Hand and not the other way around. A subclass can use what its parent provides, and it adds what the parent lacks.

Subclassing is most useful when you already have a working class that can be adapted with a few changes or additions. Designing a whole family of related classes from nothing is a bigger undertaking and is less common, especially for programmers still getting comfortable with objects. Subclassing lets you reuse the work already done so the new class stays small and focused on what makes it different.

Before writing any value logic, the rules must be clear, because subclass code is simply a translation of them. The value of a hand is found by adding up the values of its cards. Face cards are worth 10. The Ace is the only card whose value depends on context, and that dependence is what makes hand-value code tricky.

A consequence of this rule is that the first Ace in a hand may be counted as 11, but any further Aces will always be counted as 1. A second 11 would almost always push the total over 21 when combined with the first.

The clearest way to understand the Ace rule is to watch the running total change one card at a time. The following hand contains an Ace, a 6, and a 9. The 6 and 9 count at their printed values. Follow the total as each card arrives and notice the exact moment the Ace changes its value.

Read the diagram as a loop that visits each card in order. The Ace first counts as 11, giving a total of 11. The 6 raises the total to 17, which is still at or below 21, so nothing changes. The 9 raises it to 26. Because 26 is above 21, the Ace check fires: the Ace is recounted as 1, which lowers the total by 10 to 16. The change happens at the step where the running total is compared against the limit, which is the only point in the sequence where that comparison occurs.

When a subclass gives an unexpected total, the most effective debugging question is not 'why is the program wrong' but 'at which step does the value stop matching the rules'. Compare each intermediate value against the rule it should follow. The first step where the two disagree is where the divergence starts. For Blackjack hands, the most likely location is the Ace check, because it is the only step that compares the running total against a limit.