|
| |
Data Abstraction, Encapsulation, and
Arrays
A Card Game
The assignment is to write a simple card game program, using
Java classes.
Because I'm not expecting you to come up with
your own design for such a thing at this stage of the game (pun
intended), I've come up with a Program
Specification, which is in the form of javadoc-generated web pages.
As you'll see, I've broken down the problem into classes that
represent a number of abstractions:
- Card, representing a
playing card (surprise!)
- CardFace, which
represents the face value of a card
- CardSuit, which
represents a card's suit
- CardDeck, representing a
deck of cards
- CardHand, representing a
hand of cards
- CardGame, representing a
game of cards
I've also introduced a couple of abstractions that have to do
with the ability to sort:
- The abstract class
Sort,
which contains a static method quicksort()
which sorts an array of Sortables
- The interface
Sortable,
which defines what it means for a class to be sortable,
using the class Sort
Note:
At this point in the course, we probably won't have
covered interfaces yet. Don't worry about that; you won't
need to know too much about them, other than the syntax
to use when you're writing one (an interface actually
looks quite similar to a class except for the keyword interface) and how to use it from another class
(the implements keyword).
I've placed all the classes that relate to the card game into
a single package, cards, while
I've separated the Sort class and
the Sortable interface into a
different package, sort.
The specification should be abundantly clear about what you're required to
implement; it simply leaves the implementation details (how to do it)
up to you! Note that I've designed the classes in such a way that
their contents are encapsulated; that
is, their internals are not exposed to the rest of the world --
the functionality of the class is available only through a
well-defined set of public methods.
You may not change the
specification, add to it, nor subtract from it: the
implementation must match the specification correctly, and
without change. In particular, the public and private
attributes should not be changed -- this is crucial to the
concept of encapsulation and data hiding -- and the packages
specified should be used.
There's one exception to
the above: You may add a main() method to any of the classes
-- having a main() method is very useful to allow you to test
each class in isolation as you develop it. Once you've spent
time creating such main() methods, it's a good idea not to
remove them; eventually, you'll likely augment or change a
class, based on an updated specification, and you don't want
to have to reinvent the wheel all over again.
A few points:
- I've tried to structure things in such a way that it
becomes obvious what the objects are in our problem, and
how they are represented by Java classes. It should also
be clear what attributes and behavior belong in each
class.
- I'm using
CardFace and CardSuit primarily as
mechanisms to improve type safety, and also to
encapsulate the various constants (ACE, HEARTS, etc.).
- In this application,
CardGame
is pretty dumb. Its play()
method plays a card from each hand, and the highest card
wins; then the play repeats until all the cards have been
played.
- While you're implementing these classes, you'd be well
advised to develop each class as much in isolation as
possible, using a
main()
method in each class as a test harness. Since the classes
have interdependencies, you'll find it easier to create
them in a specific order.
In my solution, I developed the classes in the
approximate order:
I've even made things easier for you! Click on each of
the above classes to get a skeleton version of the source
for that class. It gets better -- CardSuit,
CardFace, Sortable,
Sort and CardGame are already completed for you. So all you have
to do is complete Card, CardDeck, and
CardHand.
You can use
CardSuit and CardFace as examples of how to implement aspects of some
of the other classes. You can use CardGame, ultimately, as a test
of your implementation.
- I fully expect you to have questions as you work on
implementing to this spec. Don't be afraid to contact me!
- Now it's time to go off and study the specification
in more detail!
|
