A Walkthrough of Roulette

A Walkthrough of Roulette
	Chapter 3. Roulette Solution Overview

A good preliminary task is to review these responsibilities to confirm that a complete cycle of play is possible. This will help provide some design details for each class. It will also provide some insight into classes that may be missing from this overview.

A good way to structure this task is to do a Class-Reponsibility-Collaborators (CRC) walkthrough. As preparation, get some 5" x 8" notecards. On each card, write down the name of a class, the responsibilities and the collaborators. Leave plenty of room around the responsibilities and collaborators to write notes. We've only identified five classes, so far, but others always show up during the walkthrough.

During the walkthrough, we identify areas of responsibility, allocate them to classes of objects and define any collaborating objects. An area of responsibility is a thing to do, a piece of information, a result. Sometimes a big piece of responsibility can be broken down into smaller pieces, and those smaller pieces assigned to other classes. There are a lot of reasons for decomposing, the purpose of this book is to explore many of them in depth. Therefore, we won't justify any of our suggestions until later in the book. For now, follow along closely to get a sense of where the exercises will be leading.

The basic processing outline is the responsibility of the Game class. To start, locate the Game card.

Our preliminary note was that this class “Runs the game.” The responsibilities section has a summary of four steps involved in running the game.
The first step is “gets bets from Player.” Find the Player card.
Does a Player collaborate with a Game to place bets? If not, update the cards as necessary to include this.
One of the responsibilities of a Player is to place bets. The step in the responsibility statement is merely “Places bets on Outcomes.” Looking at the classes, we note that the Table contains the amounts placed on the Bets. Fix the collaboration information on the Player to name the Table class. Find the Table card.
Does a Table collaborate with a Player to accept the bets? If not, update the cards as necessary to include this.
What card has responsibility for the amount of the bet? It looks like Table. We note one small problem: the Table contains the collection of amounts bet on Outcomes. What class contains the individual “amount bet on an Outcome?” This class appears to be missing. We'll call this new class Bet and start a new card. We know one responsibility is to hold the amount bet on a particular Outcome. We know three collaborators: the amount is paired with an Outcome, all of the Bets are collected by a Table, and the Bets are created by a Player. We'll update all of the existing cards to name their collaboration with Bet.
What card has responsibility for keeping all of the Bets? Does Table list that as a responsibility? We should update these cards to clarify this collaboration.

You should continue this tour, working your way through spinning the Wheel to get a list of winning Outcomes. From there, the Game can get all of the Bets from the Table and see which are based on winning Outcomes and which are based on losing Outcomes. The Game can notify the Player of each losing Bet, and notify the Player of each winning Bet, using the Outcome to compute the winning amount.

This walkthrough will give you an overview of some of the interactions among the objects in the working application. You may uncover additional design ideas from this walkthrough. The most important outcome of the walkthrough is a clear sense of the responsibilities and the collaborations required to create the necessary application behavior.