| Chapter 5. Bin Class | ||
|---|---|---|
 | Part I. Roulette |  |
| Chapter 5. Bin Class | ||
|---|---|---|
| | Part I. Roulette | |
Table of Contents
This chapter will present the design for the
Bin class. In addition to that, we'll examine the
collection classes available in Java and Python. We'll also present
present some questions and answers on this particular class and the
process of creating a design.
The Roulette wheel has 38 bins, identified with a number and a
color. Each of these bins defines a number of closely related winning
Outcomes. At this time, we won't enumerate each
of the 38 Bins of the wheel and each of the
winning Outcomes (from two to fourteen in each
Bin); we'll save that for a later exercise. At
this time, we'll define the Bin class, and use
this class to contain a number of Outcome
objects.
Two of the Bins have relatively few
Outcomes. Specifically, the 0
Bin only contains the basic “0”
Outcome and the “00-0-1-2-3”
Outcome. The 00 Bin,
similarly, only contains the basic “00”
Outcome and the “00-0-1-2-3”
Outcome.
The other 36 Bins contain the straight
bet, split bets, street bet, corner bets, line bets and various
outside bets (column, dozen, even or odd, red or black, high or low)
that will win if this Bin is selected. Each
number bin has from 12 to 14 individual winning
Outcomes.
Some Outcomes, like red or black, occur
in as many as 18 individual Bins. Other
Outcomes, like the straight bet numbers, each
occur in only a single Bin. We will have to be
sure that our Outcome objects are shared
appropriately by the Bins.
Since a Bin is just a collection of
individual Outcome objects, we have to select a
collection class to contain the objects. In Java we have five basic
choices, with some variations based on performance needs. In Python,
we have two basic choices.
The Java collections framework offers us five basic choices for defining an object that is a container for other objects.
Simple Arrays. We can always declare a collection of
Outcome objects as follows:
Outcome[] bin1 = { Outcome("Red",1),
Outcome("1",35) };. This does almost
everything that we need it to do. Since our relationship
between a Bin and the collection of
Outcomes is relatively fixed, this kind
of collection has some appeal.
java.util.Vector. With a Vector, we have the
flexibility of easy addition of an
Outcome to the collection. We also have
the power of an Iterator to visit every
member of the collection.
A Vector has an implication of
non-sequential access to the elements. In our case, we won't be
using this; most of our collections will be visited in order, as
we determine which individual bets on the table match the
Bin's collection of winning
Outcomes.
java.util.Set. A Set offers easy
addition of elements, an Iterator to
visit the elements. Additionally, it assures that each element
occurs only once. The semantics of a mathematical set are
precisely what we want for each Bin on
a wheel: it is an unordered collection of elements, each
element occurs at most one time.
The Set is appealing
because the definition precisely matches our need. Additionally,
it is possible that a Set
performs faster than a Vector or
List. The reason it can be faster
is that it does not have to keep the elements in a particular
order.
java.util.List. A List offers easy
addition of elements, an Iterator to
visit the elements. Like a Vector, a
List keeps the elements in a
particular order.
A List has an implication
of strictly sequential access to the elements. In our case, this
is generally true. Most of our collections will be built in
order and visited in order, as we determine which individual
bets on the table match the Bin's
collection of winning Outcomes. The
order, however, isn't significant, so this feature is of
relatively little value.
java.util.Map. A map is used to associate a key with a value. This
key-value pair is called an entry in the
map. We don't need this feature at all. A map does more than
we need for representing the bins on a wheel.
Having looked at the fundamental collection varieties, we will
elect to use a Set. Our next step is
to choose a concrete implementation. There are three
alternatives.
java.util.HashSet. This uses a hash code to manage the
elements in the set. The hash code can be computed almost
instantly, allowing for rapid insert and retrieval. The hash
code is mapped to buckets in an internal table. However, a
large amount of storage is wasted by the need for empty
buckets in the internal table. This trades off storage for
speed.
java.util.LinkedHashSet. This adds a doubly-linked list that preserves the
insertion order. This is not appropriate for what we are
doing, as the insertion order is largely irrelevant.
java.util.TreeSet. This uses a binary red-black tree
algorithm to store the elements of the set. The insertion time
depends on the logarithm of the size of the tree, but the
storage is minimized. This seems like the ideal candidate for
representation of each Bin.
There are three basic Python types that are a containers for other objects.
Immutable Sequence or tuple. A tuple is immutable sequence of objects.
This is the kind of collection we need, since the elements of
a Bin don't change.
Mutable Sequence or list. A list is a sequence of objects that can be changed. While handy for the initial construction of the bin, this isn't really useful because the contents of a bin don't change once they have been enumerated.
Mapping or dictionary. A dictionary associated a key with a value.
This key-value pair is called an item in
the map. We don't need this feature at all. A map does more
than we need for representing a
Bin.
Having looked at the fundamental collection varieties, we will
elect to use a tuple.
| |  | |
| Deliverables |  | Questions and Answers |