The SevenReds player waits for seven red wins in a row before betting black. This is a subclass of Player. We can create a subclass of our main Simulator to use this new SevenReds class.

We note that our previous players (Passenger57 and Martingale) are stateless: they place the same bets over and over until they are cleaned out or their playing session ends. This SevenReds player has two states: waiting and betting. In the waiting state, they are simply counting the number of reds. In the betting state, they have seen seven reds and are now playing the Martingale system on black. We will defer serious analysis of this stateful betting until some of the more sophisticated subclasses of Player. For now, we will simply use an integer to count the number of reds.

Currently, the player is not informed of the final outcome unless they place a bet. We designed the Game to evaluate the Bet instances and notify the Player of just their Bets that were wins or losses. We will need to add a method to Player to be given the overall list of winning Outcomes even when the Player has not placed a bet.

Once we have updated the design of Game to notify Player, we can add the new SevenReds class. Note that we are can intoduce each new betting strategy via creation of new subclasses. A relatively straightforward update to our simulation main program allows us to use these new subclasses. The previously working subclasses are left in place, allowing graceful evolution by adding features with minimal rework of existing classes.

In addition to waiting for the wheel to spin seven reds, we will also follow the Martingale betting system to track our wins and losses, assuring that a single win will recoup all of our losses. This makes SevenReds a further specialization of Martingale. We will be using the basic features of Martingale, but doing additional processing to determine if we should place a bet or not.

Introducing a new subclass should be done by upgrading the main program. See Soapbox on Composition for comments on the ideal structure for a main program. Additionally, see our Why does the Game class run the sequence of steps? Isn't that the responsibility of some “main program?” FAQ entry and Why are we making the random number generator more visible? Isn't object design about encapsulation? FAQ entry for more discussion.

Soapbox on Composition

Generally, a solution is composed of a number of objects. However, the consequences of this are often misunderstood. Since the solution is a composition of objects, it falls on the main method to do just the composition and nothing more.

Our ideal main program creates and composes the working set of objects. In this case, it should decode the command-line parameters, and use this information to create and initialize the simulation objects, then start the processing. For these simple exercises, however, we're omitting the parsing of command-line parameters, and simply creating the necessary objects directly.

Our main program should, therefore, look something like the following:

Example 14.1. Java Main Program

Random theRNG= new Random(); 
Wheel theWheel= new Wheel( theRNG );
Table theTable= new Table();
Game theGame= new Game( theWheel, theTable );
Player thePlayer= new SevenReds( table ); 
Simulator sim= new Simulator( theGame, thePlayer );
sim.gather(); 

	This can also use NonRandom. The idea is that we build up the functionality of Wheel by composition. We compose the wheel of the bins plus the number generator.
	This can also be Martingale or Passenger57 (who always bets on black). Again, we have assembled the final simulation by composition of a Wheel (and its generator), the Table and the specific Player algorithm.
	This is the actual work of the application, done by the Simulator, using the Game and Player objects built by main.

In many instances, the construction of objects is not done directly by the main method. Instead, the main method will construct a base group of Abstract Factory and Builder objects. Given these objects and the command-line parameters, the application objects can be built. The application objects then collaborate to perform the required functions.