Comp202: Principles of Object-Oriented Programming II
Fall 2006 -- Design of a Card Game   

The goal of this exercise is to design an appropriate object model for a framework to play a variety of card games such as Blackjack, Solitaire, etc.   The assignment is broken down into two phases, described below.

Phase 1: Design the Card Game Framework

Card Game Specifications

When we play a game of cards, we perform certain actions on the cards and/or decks of cards.  For examples, an action may be to flip a card and another action may be to take cards from one deck and insert them into another deck.  The rules of a particular game dictate if and when certain action can be carried out.  Thus to model card games, we need to model:


An action is something that the card player is requesting to perform on a card and/or decks of cards.  For example, a card that is face down can be  flipped  to be face up and vice-versa.   The rules of a particular card game decide if and when such an action can be performed.  Note that not every object in the system should have the privilege to perform an action, not even the player (e.g. to prevent cheating).


The rule decides whether or not a given action can be performed and may even carry out the action if the action is legal.  Since the player can request any action, the rule cannot know a priori what action it is dealing with and thus should be decoupled from the actions.


In any given game,


In a particular card game, one situation may only consider rank and suit while another situation may only consider rank and color.  For example, in the game of Solitaire, the goal is to move appropriate cards around to make four stacks of cards, where each card must be of the same suit and ordered according to rank.  In doing so, the cards may be placed into temporary card piles where only rank and color matter.  In contrast to Solitaire, there are games akin to Blackjack that only consider the rank.  Thus, the card design must be flexible enough to accommodate all possible considerations of face, rank, suit and color in order to be used in a large variety of games.  The games that we want to play may be extant well-known card games or may be some new games that we just invent!

Some games, such as variants of Solitaire, differ only in a few rules, such as alternating vs. matching colors in a stack of cards.  Handling such a small variant change in specification should require minimal code modification.  That is, your design should be such that a delta change in specification engenders only a delta change in the code.


You must work as a team of at most two people to design a model for playing cards that meets the above specifications.  Discussions about design are crucial in creating good design!


  1. Draw the UML class diagrams for your design (using your favorite UML tool).  Sequence diagrams are not required.
  2. Write the Java code and javadoc for the classes and interfaces in your design.   
  3. The design documentation need not be extensive but should be concise and clear enough to describe your classes, interfaces and methods. 
  4. Be sure to state what design patterns you are using.  For example,  if IVis is the visitor interface for the host class Host, then all you need to document is the IVis is the visitor for Host without having to describe each visiting method and their parameters, and for the visitor hook method in Host, simply state that this is the visitor hook method.

Proof of Concept

Suppose in a game akin to Solitaire you have a list of cards and want to insert another card at the front of this list .  The rules of the game in this situation are as follows.

  1. You can only insert a face up card.
  2. If the card at the front of the list is face down, then you cannot insert any new card at all.  But if it is face up then you can insert the new card only when the rank of the new card is one lower than the current front card and is of a different color. 
  3. And when the list is empty (don't forget the empty case!), you can only insert a King of any suit.

Using your design, write the Java code to implement the above insertion rules and an appropriate JUnit test class to test your rules. 

Have your design and documentation completed and turned in by the start of the lab for Phase 2.

Phase 2:  Discussion and Comparison

You are required to spend the next lab time presenting your design, discussing and comparing it against other designs.

  1. Each team will have 20 minutes to present their design and 5 minutes for Q&A.
  2. The instructors will have 20 minutes to present their design and 5 minutes for Q&A.
  3. Afterwards, the relative merits between the various designs will be discussed.


Evaluation Criteria

In judging a design, we look for:

  1. correctness: does the behavior of the system correctly implement the specification?  Our thesis is the closer the OO model reflects the problem we are trying to solve, the simpler the code and the easier it is to check for correctness.
  2. modularity: are the classes organized in a cohesive manner and in such a way that they can be developed and tested in "small" and independent units?
  3. extensibility: can we add more (unforeseen) functionalities to the system without incurring any changes?
  4. flexibility: can we make "reasonable" changes to the system without breaking all the pieces of the system, that is a small change in one class only affects a manageable number of changes in other classes?
  5. robustness: how much intentional/unintentional abuses can the system take from the clients without breaking?

In judging a presentation, we look for

  1. organization: are the various design elements presented in an organized fashion?
  2. thoroughness: does the presentation cover all the key design issues and how they are resolved?
  3. clarity: are the ideas presented in a clear, easy-to-follow manner?
  4. enthusiasm: is the presentation lively and engaging or dry and monotonous?



Last Revised Thursday, 03-Jun-2010 09:52:20 CDT

©2006 Stephen Wong and Dung Nguyen