Comp202: Principles of Object-Oriented Programming II
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.
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!
- Draw the UML class diagrams for your design (using your favorite UML tool). Sequence diagrams are not required.
- Write the Java code and javadoc for the classes and interfaces in your design.
- The design documentation need not be extensive but should be concise and clear enough to describe your classes, interfaces and methods.
- 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.
- You can only insert a face up card.
- 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.
- 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.
- Your code should have as few "if" and other flow control constructs as possible.
- Use LRStruct (i.e. a mutable list) to represent the deck of cards. You may use either the generic or non-generic version of LRStruct.
- Your proof-of-concept documentation need not be extensive but should be clear and concise.
Have your design and documentation completed and turned in by the start of the lab for Phase 2.
You are required to spend the next lab time presenting your design, discussing and comparing it against other designs.
In judging a design, we look for:
In judging a presentation, we look for
Last Revised Thursday, 03-Jun-2010 09:52:27 CDT
©2007 Stephen Wong and Dung Nguyen