| Chapter 7. Bin Builder Class | ||
|---|---|---|
 | Part I. Roulette |  |
| Chapter 7. Bin Builder Class | ||
|---|---|---|
| | Part I. Roulette | |
Table of Contents
This is a rather long chapter, which describes a number of design
considerations surrounding Outcome,
Bin and Wheel. The second
section presents a number of algorithms to group
Outcomes based on the geometry of the table.
These algorithms are presented at a high level, leaving much of the
detailed design to the student.
It is clear that enumerating each Outcome
in the 38 Bins is a tedious undertaking. Most
Bins contain about fourteen individual
Outcomes. It is often helpful to create a class
that is used to build an instance of another class. This is a design
pattern sometimes called a Builder.
We'll design an object that builds the various
Bins and assigns them to the
Wheel. This will fill the need left open in the
design of the
Wheel class.
Additionally, we note that the complex algorithms to construct
the Bins are only tangential to the operation
of the Wheel object. While not essential to the
design of the Wheel class, we find it is often
helpful to segregate these rather complex builder methods into a
separate class.
The BinBuilder class will have a method
that enumerates the contents of each of the 36 number
Bins, building the individual
Outcome instances. We can then assign these
Outcome objects to the
Bins of a Wheel
instance. We will use a number of steps to create the various types of
Outcomes, and depend on the
Wheel to assign each
Outcome object to the correct
Bin.
Looking at the layout of a
Roulette table gives us a number of geometric rules for
determining the various Outcomes that are
combinations of individual numbers. These rules apply to the numbers
from one to thirty-six. A different -- and much simpler -- set of
rules applies to 0 and 00. First, we'll survey the table geometry,
then we'll develop specific algorithms for each kind of bet.
Split Bets. Each number is adjacent to two, three or four other numbers. The four corners (1, 3, 34, and 36) only participate in two split bets. The center column of numbers (5, 8, 11, ..., 32) each participate in four split bets. The remaining “edge” numbers participate in three split bets. While this is moderately complex, the bulk of the layout (from 4 to 32) can be handled with a simple rule to distinguish the center column from the edge columns. The ends (1, 2, 3, 34, 35 and 36) are a little more complex.
Street Bets. Each number is a member of one of the twelve street bets.
Corner Bets. Each number is a member of one, two or four corner bets. As with split bets, the bulk of the layout can be handled with a simple rule to distinguish the column, and hence the “corners”. A number in the center column (5, 8, 11, ..., 32) is a member of four corners. At the ends, 1, 3, 34, and 36, are members of just one corner. All of the remaining numbers are along an edge and are members of two corners.
Line Bets. Six numbers comprise a line; each number is a member of one or two lines. The ends (1, 2, 3 and 34, 35, 36) are each part of a single line. The remaining 10 rows are each part of two lines.
Dozen Bets. Each number is a member of one of the three dozens. The three ranges are from 1 to 12, 13 to 24 and 25 to 36, making it very easy to associate numbers and ranges.
Column Bets. Each number is a member of one of the three columns. Each of the columns has a number numeric relationship. The values are 3c+1, 3c+2, and 3c+3, where c varies from 0 to 11.
The Even-Money Bets. These include Red, Black, Even, Odd, High, Low. Each
number has three of the six possible even money
Outcomes. An easy way to handle these is
to create the 6 individual Outcome
instances. For each number, n, individual
if-statements can be used to determine which of the
Outcome objects are associated with the
given Bin.
The Bins for zero and double zero can
easily be enumerated. Each bin has a straight number bet
Outcome, plus the Five Bet
Outcome (00-0-1-2-3, which pays 6:1).
One other thing we'll probably want are handy names for the
various kinds of odds. While can define an
Outcome as Outcome( "Number 1",
35 ), this is a little opaque. A slightly nicer form
is Outcome( "Number 1", RouletteGame.StraightBet
). These are specific to a game, not general features
of all Outcomes. We haven't designed the game
yet, but we can provide a stub class with these these outcome odds
definitions.
An an advanced topic, we need to avoid hard coding the names of the bets. Both Java and Python provide extensive tools for localization (l10n) of programs. Since both applications already use Unicode strings, they support non-Latin characters, handling much of the internationalization (i18n) part of the process.
Java Localization. This application's bet names should be fetched from
resource bundles so that we can change the bet names without
making changes to BinBuilder and all of
the various subclasses of Player that use
various kinds of bets.
There are number of localization features in Java. We can
specify a Locale object, which provides a
number of defaults for the formatters in the
java.text package and resource bundles with
Strings that will be displayed to people.
We won't dwell on the l10n issue. However, the right
preparation for l10n is to isolate all Strings used for messages,
and format all dates and numbers with formatters found in the
java.text package. In this case, our
Outcome names may be displayed, and should
be isolated into a separate object. Even something as simple as
blackBetName = "Black"; will set
the stage for fetching strings from resource bundles.
Python Localization. Python localization depends on the
locale and gettext
modules. The locale module provides a
number of functions and constants to help format dates and times
for the user's selected locale. The
gettext module provides a mechanism for
getting translated text from a message catalog with messages in
a variety of languages.
We won't dwell on the l10n issue. However, the right
preparation for l10n is to isolate all Strings used for messages,
and format all dates and numbers with formatters found in the
locale module. In this case, our
Outcome names may be displayed, and should
be isolated into a separate object. Even something as simple as
blackBetName = _("Black") will
set the stage for fetching strings from a
gettext message catalog.
In order to define the
_(string) function, the following
fragment should be used. While not ubiquitous in Python programs,
doing this now establishes a standard practice that will permit
easy localization of an application program.
Example 7.1. Python Localization
import gettext gettext.NullTranslations().install()print _("String To Be Translated")
| |  | |
| Deliverables |  | Algorithms |