Players, the Game Loop, and Class Relationships

1. Players, the Game Loop, and Class Relationships

Title

Think Java 2e · Chapter 14 · Extending Classes

Sections 14.4-14.6 · pp. 240-247

2. What you will be able to do

Objectives

This lesson follows Think Java 2e, Chapter 14 (Extending Classes), Sections 14.4-14.6, pp. 240-247. Everything on these slides can be checked against those pages.

1. Separate game rules from reusable card classes, and say why that separation is worth keeping.

2. Write a strategy method that delegates to helper methods for its two cases.

3. Explain bottom-up design and contrast it with top-down design.

4. Trace a game loop that alternates between two players until one hand is empty.

5. Distinguish composition (HAS-A) from inheritance (IS-A).

6. Read and draw a UML class diagram using both kinds of arrow.

• 14.4 — The Player Class
• 14.5 — The Eights Class
• 14.6 — Class Relationships

3. Retrieve before you read

Warm-up

Two ideas the chapter is about to use by name.

4. The rules, at last

Concept

The Deck and Hand classes we have defined so far could be used for any card game; we have not yet implemented any of the rules specific to Crazy Eights. But now it's time to implement the rules.

• 14.4 — the Player class: strategy, and top-down design again
• 14.5 — the Eights class, built bottom-up
• 14.6 — class relationships: HAS-A and IS-A

Downey & Mayfield, Think Java, 2nd edition (Green Tea Press / O'Reilly, 2020) — Think Java 2e, Chapter 14 (Extending Classes), Sections 14.4-14.6, pp. 240-247 — Section 14.4 opens on printed page 240.

5. The Player class

Section

Section 14.4

6. A player has a name and a hand

Concept

We'll use two classes: Player, which encapsulates player strategy, and Eights, which creates and maintains the state of the game.

public class Player {
    private String name;
    private Hand hand;

    public Player(String name) {
        this.name = name;
        this.hand = new Hand(name);
    }
}

A Player has two private attributes: a name and a hand. The constructor takes the player's name as a string and saves it in an instance variable. In this example, we have to use this to distinguish between the instance variable and the parameter with the same name. Lesson 14a dropped this everywhere it was optional — this is a place it is not.

7. A Player has a Hand, and a Hand is a CardCollection

Picture it

Both relationships in one picture. The arrows point differently on purpose.

Hand IS-A CardCollection; Player HAS-A Hand. A Player cannot be dealt cards directly and never should be — every card operation goes through hand, which is exactly the boundary composition draws.

8. The play method, and top-down design again

Worked example

The primary method that Player provides is play, which decides which card to discard during each turn. It is five lines and neither helper exists yet.

public Card play(Eights eights, Card prev) {
    Card card = searchForMatch(prev);
    if (card == null) {
        card = drawForMatch(eights, prev);
    }
    return card;
}

9. What does searchForMatch return when nothing matches?

Prediction

The loop finishes without finding anything.

for (int i = 0; i < hand.size(); i++) {
    ...
}
return null;

10. The two helpers

Concept

searchForMatch looks in the player's hand for a card that matches the previously played card. drawForMatch handles the other case.

public Card searchForMatch(Card prev) {
    for (int i = 0; i < hand.size(); i++) {
        Card card = hand.getCard(i);
        if (cardMatches(card, prev)) {
            return hand.popCard(i);
        }
    }
    return null;
}

The strategy is pretty simple: the for loop searches for the first card that's legal to play and returns it. Exercise 14.1 asks you to do better — playing an eight only when you must, or the highest-ranking card first — by writing a subclass that overrides play.

11. Returning the card without removing it

Trap

if (cardMatches(card, prev)) {
    return hand.getCard(i);      // the card is STILL in the hand
}

if (cardMatches(card, prev)) {
    return hand.popCard(i);
}

12. Which class knows what?

Definition probe

The rules live in exactly one place.

13. Search the hand

Fill the middle

Read each card, and remove the one you play.

14. Why does play take the Eights object?

Socratic

It only needs one card from it.

15. Drawing and matching

Section

Section 14.4

16. Draw until you get a match

Concept

When players don't have a matching card or an eight, they must draw new cards until they get one. That rule translates into a loop with no obvious end.

public Card drawForMatch(Eights eights, Card prev) {
    while (true) {
        Card card = eights.drawCard();
        System.out.println(name + " draws " + card);
        if (cardMatches(card, prev)) {
            return card;
        }
        hand.addCard(card);
    }
}

The while loop runs until it finds a match (we'll assume for now that it always finds one). That parenthesis is the book being honest: while (true) with a return inside is correct only if a match eventually turns up.

17. while (true) with a return in the middle

Notation

The loop has no condition. Everything that ends it is inside the body.

A while (true) is not automatically bad, but it is a promise you are making. Here the promise is that a match exists — reasonable, since eights are wild and there are four of them.

18. Translating the rules into cardMatches

Worked example

This method is a straightforward translation of the rules of the game. Read the rule and the code side by side.

public static boolean cardMatches(Card card1, Card card2) {
    return card1.getSuit() == card2.getSuit()
        || card1.getRank() == card2.getRank()
        || card1.getRank() == 8;
}

19. Do these two cards match?

Prediction

Apply the three clauses.

Card prev = new Card(13, 2);   // King of Hearts
Card card = new Card(8, 0);    // 8 of Clubs
cardMatches(card, prev)

20. Where cardMatches really belongs

Concept

The book flags its own compromise. When we designed the program for this chapter, we tried to minimize the number of classes. As a result, we ended up with a few awkward methods.

The problem is that Card is supposed to be useful for any card game, not just Crazy Eights. You can solve this problem by adding a new class, EightsCard, that extends Card and provides a method, match. That is Exercise 14.4 — and it is inheritance used to add a game's rules without contaminating the reusable class.

21. Putting the game rule in Card

Trap

public class Card {
    public boolean matches(Card that) {
        return this.suit == that.suit
            || this.rank == that.rank
            || this.rank == 8;      // Crazy Eights only
    }
}

// Exercise 14.4's answer:
public class EightsCard extends Card {
    public boolean match(EightsCard that) { ... }
    public int scoreCard() { ... }
}

// the book's own compromise: a static method in Player
public static boolean cardMatches(Card c1, Card c2) { ... }

22. Which class should own the rule?

Definition probe

Reusability is the deciding question.

23. Write the matching rule

Fill the middle

Suit, or rank, or a wild eight.

24. Could drawForMatch loop forever?

Edge cases

We'll assume for now that it always finds one.

25. Bottom-up design

Section

Section 14.5

26. Start from the pieces, not the outline

Concept

In Section 13.2 we introduced top-down design. In this way of developing programs, we identify high-level goals and break them into smaller problems. In this section, we present bottom-up design, which goes the other way around: first we identify simple pieces we need and then we assemble them into more-complex algorithms.

// looking at the rules, we can identify some methods we'll need:
//   set up the game                      (Eights constructor)
//   check whether the game is over        (isDone)
//   shuffle the discard pile into the draw pile   (reshuffle)
//   draw a card, reshuffling if necessary (drawCard)
//   switch from one player to the next    (nextPlayer)
//   display the state and wait for input  (displayState)

bottom-up design — A way of developing programs by identifying simple pieces, implementing them first, and then assembling them into more-complex algorithms.

Looking at the rules of Crazy Eights, we can identify some of the methods we'll need. The rules are already a list of things that must happen — so reading them off is faster than inventing an outline.

27. The state of the game

Notation

Before any method, the attributes. Here is the beginning of the class definition for Eights, which encapsulates the state of the game.

Reading a class's attributes tells you what it is responsible for. Eights owns the piles and the players; it does not own a strategy, which is why play lives in Player.

28. reshuffle, and the card you must not lose

Worked example

If the draw pile ever runs out, the discard pile is shuffled (except the top card) and becomes the new draw pile. Four lines, and the order of them is the whole method.

public void reshuffle() {
    Card prev = discardPile.popCard();
    discardPile.dealAll(drawPile);
    discardPile.addCard(prev);
    drawPile.shuffle();
}

public Card drawCard() {
    if (drawPile.isEmpty()) {
        reshuffle();
    }
    return drawPile.popCard();
}

29. How many cards are in the discard pile after reshuffle?

Prediction

It had 30; the draw pile had 0.

Card prev = discardPile.popCard();
discardPile.dealAll(drawPile);
discardPile.addCard(prev);

30. drawCard and nextPlayer

Concept

Two more pieces, each three or four lines, each hiding one rule from everything that calls it.

public Player nextPlayer(Player current) {
    if (current == one) {
        return two;
    } else {
        return one;
    }
}

nextPlayer takes the current player as a parameter and returns the player who should go next. Note current == one compares references — which is right here, because the question really is is this the same object, not is this an equal player. That is Lesson 11b's identity, being the correct choice for once.

31. Dealing away the top of the discard pile

Trap

public void reshuffle() {
    discardPile.dealAll(drawPile);   // the top card goes too
    drawPile.shuffle();
}

Card prev = discardPile.popCard();
discardPile.dealAll(drawPile);
discardPile.addCard(prev);
drawPile.shuffle();

32. Top-down or bottom-up?

Definition probe

Two design processes, used in two chapters.

33. Draw a card safely

Fill the middle

The pile might be empty.

34. Why is bottom-up a good fit here?

Explain it to yourself

Chapter 13 used top-down for shuffle.

35. The game loop

Section

Section 14.5

36. One turn

Concept

Using these pieces, we can write takeTurn, which executes one player's turn. Five lines, and every one of them calls something written earlier.

public void takeTurn(Player player) {
    Card prev = discardPile.lastCard();
    Card next = player.play(this, prev);
    discardPile.addCard(next);
    System.out.println(player.getName() + " plays " + next);
    System.out.println();
}

It reads the top card off the discard pile and passes it to player.play, which you saw in the previous section. The result is the card the player chose, which is added to the discard pile. Note lastCard rather than popCard — the card stays on the pile.

37. One turn, end to end

Picture it

Five objects cooperate and each one does only its own job.

The Eights object never looks at a card's rank or suit, and the Player never touches the draw pile directly. Each asks the other for what it needs — which is what the two-way play(this, prev) call is for.

38. playGame

Worked example

Finally, we use takeTurn and the other methods to write playGame. Every piece from the bottom-up list appears exactly once.

public void playGame() {
    Player player = one;

    // keep playing until there's a winner
    while (!isDone()) {
        displayState();
        takeTurn(player);
        player = nextPlayer(player);
    }

    // display the final score
    one.displayScore();
    two.displayScore();
}

39. When does playGame stop?

Prediction

isDone checks both hands.

public boolean isDone() {
    return one.getHand().isEmpty() || two.getHand().isEmpty();
}

40. Alternating without a counter

Concept

player = nextPlayer(player) is worth a second look — it alternates without any index or modulo arithmetic.

Player player = one;
while (!isDone()) {
    takeTurn(player);
    player = nextPlayer(player);   // one -> two -> one -> two
}

Modify the Eights class to create an ArrayList of players, and modify nextPlayer to select the next player — that is Exercise 14.3, and notice that only nextPlayer and the constructor would change. playGame and takeTurn are already written in terms of the next player, so they need no edit at all.

41. Popping the card you need to match

Trap

public void takeTurn(Player player) {
    Card prev = discardPile.popCard();   // takes it OFF the pile
    Card next = player.play(this, prev);
    discardPile.addCard(next);
}

Card prev = discardPile.lastCard();
Card next = player.play(this, prev);
discardPile.addCard(next);

42. What does takeTurn add to the discard pile?

Prediction

It reads one card and adds another.

Card prev = discardPile.lastCard();
Card next = player.play(this, prev);
discardPile.addCard(next);

43. Who is responsible?

Definition probe

State against strategy.

44. Could playGame handle four players unchanged?

Counterexample

Exercise 14.3 asks for exactly that.

45. Class relationships

Section

Section 14.6

46. HAS-A and IS-A

Concept

This chapter demonstrates two common relationships between classes. You have used both; now they have names.

HAS-A — A relationship between two classes in which one class has an instance of another class as one of its attributes.

IS-A — A relationship between two classes in which one class extends another; the subclass is an instance of the superclass.

This vocabulary provides a concise way to talk about an object-oriented design. Two words settle a question that otherwise takes a paragraph — and they are the test Lesson 14a used before they had names.

47. The whole program in one diagram

Picture it

Figure 14.1 shows the classes defined in this chapter and the relationships among them. Two kinds of arrow, and they mean different things.

Composition arrows have a standard arrowhead, and inheritance arrows have a hollow triangle head, usually pointing up. UML is an international standard, so almost any software engineer in the world could look at this diagram and understand our design.

48. Reading the relationships aloud

Worked example

Every arrow in the diagram is a sentence. Say each one and check it is true.

Eights   HAS-A  Player       "an Eights has a Player"
Eights   HAS-A  Hand         "an Eights has a draw pile"
Eights   HAS-A  Scanner      "an Eights has a Scanner"
Player   HAS-A  Hand         "a Player has a Hand"
Hand     IS-A   CardCollection   "a Hand is a CardCollection"
Deck     IS-A   CardCollection   "a Deck is a CardCollection"

49. HAS-A or IS-A?

Definition probe

Say the sentence out loud.

50. Everything you have built, in six classes

Concept

Three chapters, six classes, and every one of them holds a decision the others do not need to know.

And class diagrams are only one of many graphical representations defined in the UML standard. The diagram is worth drawing before the code as well as after — it is where a wrong relationship shows up cheaply.

51. Drawing the arrows the wrong way round

Trap

// wrong reading:
CardCollection ---|> Hand      "a CardCollection is a Hand"

// and a plain arrow used for inheritance:
Hand -----------> CardCollection

Hand -----------|> CardCollection    "a Hand IS-A CardCollection"
Player --------->  Hand              "a Player HAS-A Hand"

52. Which arrowhead?

Prediction

Two notations, two meanings.

// Hand extends CardCollection
// Player has a Hand

53. Match the term to its meaning

Matching

The chapter's vocabulary.

54. Why does a shared notation matter?

Real world

UML is an international standard.

55. The three design processes

Comparison

Fill the blanks.

The last row is the point. The result of bottom-up design is similar to top-down: we have a high-level method that calls helper methods. The difference is the development process we used to arrive at this solution.

56. The pattern to carry away

Pattern

Separate what a thing is from what a game does with it, and use the two relationships accordingly.

// reusable: knows nothing about any game
public class Card { ... }
public class CardCollection { ... }
public class Hand extends CardCollection { ... }   // IS-A

// game-specific: knows the rules
public class Player {
    private Hand hand;                             // HAS-A
    public Card play(Eights eights, Card prev) { ... }
    public static boolean cardMatches(Card c1, Card c2) {
        return c1.getSuit() == c2.getSuit()
            || c1.getRank() == c2.getRank()
            || c1.getRank() == 8;                  // the rule lives HERE
    }
}

• Say the relationship aloud — is a or has a — before choosing.
• Keep game rules out of reusable classes, or add them by extending.
• Bottom-up when you know the pieces, top-down when you know the shape.
• lastCard reads; popCard removes — and a game depends on the difference.

57. Check: relationships

Check

Work it out before you click.

public class Player {
    private String name;
    private Hand hand;
}

public class Hand extends CardCollection { ... }

58. Check: reshuffle

Check

Work it out before you click.

public void reshuffle() {
    Card prev = discardPile.popCard();
    discardPile.dealAll(drawPile);
    discardPile.addCard(prev);
    drawPile.shuffle();
}

59. Check: takeTurn

Check

Work it out before you click.

Card prev = discardPile.lastCard();
Card next = player.play(this, prev);
discardPile.addCard(next);

60. Strategy as a separate class

Real world

Design a better strategy for the Player.play method. Write a new class that extends Player and overrides play to implement your strategy.

61. How sure are you?

Commit first

Commit to an answer and to your confidence.

62. Explain it to someone else

Explain it

Two minutes, out loud.

63. Exit ticket

Exit ticket

One question before you close the deck.

64. Draw the whole lesson

Connect it up

One page, from memory.

65. Recap

Recap

Three sections that add the rules, name the design process, and name the relationships.

• Player encapsulates strategy; Eights encapsulates the state of the game.
• play searches the hand first, then draws until it finds a match.
• cardMatches is a straightforward translation of the rules — suit, rank, or an eight.
• Bottom-up design identifies the simple pieces first, then assembles them.
• reshuffle saves the top card, moves the rest, puts it back, and shuffles.
• lastCard reads the top card; popCard removes it — takeTurn needs the first.
• Composition is HAS-A: an Eights has a Scanner.
• Inheritance is IS-A: a Hand is a CardCollection.