Object-Oriented Design Concepts via Playing Cards
Owen Astrachan
Duke University
Most students have played card games: blackjack, war, hearts, solitaire, bridge.
The list of games isn't infinite, but it's practically unbounded. In this design
exposition, we'll discuss the design and implementation of a playing card class.
We'll talk about issues in designing classes to represent both a deck of cards and
piles of cards used in different games. The Web site that accompanies this design
discussion includes references, code, and exercises for many assignments and in-
class discussions. In this document we'll concentrate on the playing card classes and the deck
class to keep things simple.
Students and teachers often wonder when it's appropriate to use a Java interface
rather than a class. Some designers and educators think all object-oriented designs
should start with interfaces. It is hard to motivate this stance with only a simple
appeal to experts as a justification. In the design of a playing card class, our
scenario begins with a teacher providing an initial specification and code to
students and then asking them to write programs that play games with cards. Our
goal is for one student's game or player to interact with another's. We'd also like to ensure that
student-written code for a card player does not change the cards that are dealt. Using an interface
provides a simple way for students to use cards in the code they write without having access to a
card's internals, without being able to create a specific card, and without knowing how cards are
implemented. This process begins with the code for a card interface, an interface we call ICard.1
public interface ICard extends Comparable
{
public static final int SPADES = 0;
public static final int HEARTS = 1;
public static final int DIAMONDS = 2;
public static final int CLUBS = 3;
public int getSuit();
public int getRank();
}
The interface specifies the behavior of a card without providing informat