Why is it technically possible to represent a playing card using six Boolean values? Rewrite class Card so that it is internally represented as six Boolean values. What is the impact of this change of the maintainers of class Card? What is the impact of this change on the users of class Card?
Re-implement class Card as a single enumerated type. For the purpose of the Solitaire application, does this look like a superior or inferior solution to this version? Why? Try writing down your answer in specific terms using terminology seen in Chapter 2.
Add a static method random() to class Card that returns a random card. What is the benefit of placing this method in class Card as opposed to another class, for example CardUtilities?
Modify the Suit enumerated type to include a method color() that returns the color of the suit. The return type should be a new enumerated type Color.
The following code was the victim of the Primitive Obsession antipattern combined with an evil naming scheme. Conceptually, what could it possibly do? Assume the code is written in relation to the development of a card game.
public static void main(String[] args) {
Random r = new Random();
int[] cs = new int[10];
int i = 0;
while (i < 10) {
int c = r.nextInt(52);
while (c % 13 > 10) {
c = r.nextInt(52);
}
cs[i] = c;
i++;
}
int s = 0;
for (int j : cs) {
s += j % 13 + 1;
}
System.out.println("Result: " + s);
}Refactor this code to use the Card, Suit, and Rank types to clean up the implementation. For this exercise, the process is more important than the outcome. Using IDE tools, start by renaming variables intelligently, then introduce high-level types as appropriate. Use your solution to Exercise 3.
Add a method to class Card that returns the next card in a circular sequence defined by the order of ranks and suits. For example, the card that follows the Two of Clubs is the Three of Clubs, and the card that follows the King of Hearts is the Ace of Clubs.
Modify class Card to support the concept of a "Joker" (a special card that is not in any suit) while keeping the class as encapsulated as possible.
Further modify your class to support any number of distinct jokers. For example, a "high" joker vs. a "low" joker, or even three jokers, etc. Again, try to keep things encapsulated and respectful of the class design guidelines seen in the chapter.
Extend the class Deck to include a copy constructor.
Create a new class called MultiDeck that contains a list of decks (some card games require multiple decks). Make the class copyable through a copy constructor. First, make a shallow copy of the decks contained. Use the debugger to confirm that the decks in a multi-deck are shared between an original multi-deck and its copies. Then, use deep copying to make copied multi-decks independent from each other. Use design by contract and the assert statement to clarify the class's interface.
Create a UML Object Diagram of a MultiDeck instance with two decks.
Improve the code of TwelveDays to take advantage of enumerated types.
Hint 1: Remember that you can define fields and methods in enumerated types.
Hint 2: Try implementing your solution using StringJoiner.
Check out Solitaire 1.3. Re-write the Deck class so that instead of representing a shuffled deck of cards, it construct objects with a pre-determined order of cards that allows you to win the game. Run the application to play (and win) a few games.
For an additional challenge, revise the design of the Deck class so it supports a small number of winnable configurations, and figure out how to select the desired configuration by passing a command-line argument to the application.
No solution is provided for starred exercises.
Unless otherwise noted, the content of this repository is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Copyright Martin P. Robillard 2019-2025