Assignment 3

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. 

  • Why do think I did this?

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 andCardGame 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!