Tracking the Progress of the Wordz Game

Designing game progress tracker

The next design decisions concern the expected outcome of starting a new game for a player. There are two things that need to be recorded:

• The selected word that the player attempts to guess.

• That we expect their first guess next.

The selected word and current attempt number will need to persist somewhere. We’ll use the repository pattern to abstract that. Our repository will need to manage some domain objects. Those objects will have the single responsibility of tracking our progress in a game.

Selecting class names and responsibilities

We already see a benefit of TDD in terms of rapid design feedback. We haven’t written too much code yet, but already, it seems like the new class needed to track game progress would best be called class Game. However, we already have a Game class, which is responsible for starting a new game. TDD is providing feedback on our design—that our names and responsibilities are mismatched.

We must choose one of the following options to proceed:

• Keep our existing class Game as it is. Call this new class something else, such as Progress or Attempt.

• Change the start() method to a static method—a method that applies to all instances of a class.

• Rename the Game class to something that better describes its responsibility. Then, we can create a new Game class to hold the current player’s progress.

The static method option is unappealing. When using object-oriented programming in Java, static methods rarely seem as good a fit as simply creating another object that manages all the relevant instances. The static method becomes a normal method on this new object.

Refactoring code

Using the Game class to represent progress through a game seems to result in more descriptive code. Let’s go with that approach.

• We use the IDEA IDE to refactor/rename the Game class Wordz, which represents the entry point into our domain model. We also rename the local variable game to match: