Designing a Card Game Program
Nouns in a problem description are candidate classes, and simple values such as suit and value are usually instance variables of a class like Card.
Turning Ordinary Prose into a Design
Object-oriented design often begins before any code is written. A programmer is handed a description of what a system must do, usually written in ordinary language. Nothing in that description is labeled as a class or a method. The designer has to read it with a specific question in mind: which of these words name things, and which of them name things that happen?
This article follows that reading process using a card game. Imagine a designer reading the game's description for the first time. The goal is to turn a paragraph of prose into a short list of candidate classes and candidate methods. Those candidates are not final decisions. They are a starting point that the designer refines as the program takes shape.
What do you think happens?
The description says cards can be added to and removed from hands. Which word is the candidate class, and which words are the candidate methods?
Reveal answer
The noun hand is the candidate class. The two verbs give the candidate methods addCard() and removeCard().
The noun names a thing that will exist in the program, so it is a candidate class. The verbs name actions, so each becomes a candidate method. The source works through this exact sentence to show how each decision stays tied to a phrase in the description.
Reading the Description One Sentence at a Time
The most reliable way to build a candidate list is to process the description sentence by sentence. Each sentence is examined for nouns and verbs, and each noun or verb that matters is recorded along with the phrase that justified it. Keeping every decision tied to a specific phrase is what prevents the list from becoming a guess.
The first pass over the card game produces nouns for the game, the player, the hand, the card, and the deck. The source explicitly notes that a complete program might give classes to all five. A designer working on a first version does not have to tackle everything at once. The source starts with the three nouns that are most obviously reusable: Card, Hand, and Deck. Choosing a focused starting set is a deliberate design decision, and it leaves the remaining nouns available for later.
| Phrase in the description | What it contributes | Candidate decision |
|---|---|---|
| the game | A noun naming a thing in the system | Candidate class, but not in the first focused set |
| the player | A noun naming a thing in the system | Candidate class, but not in the first focused set |
| the hand, cards added to and removed from it | A noun plus two verbs | Class Hand with methods addCard() and removeCard() |
| the card, with its suit and value | A noun whose simple values are described | Class Card, with suit and value as instance variables |
| the deck, which is shuffled and dealt from | A noun plus two verbs | Class Deck with methods shuffle() and dealCard() |
A running record of how each phrase contributes to the candidate list. The final column is a starting decision, not a permanent one.
Deciding Between a Class and an Instance Variable
Not every noun deserves its own class. The source's summary states the rule directly: nouns in a problem description are candidate classes, and simple values such as suit and value are usually instance variables of a class like Card. The question a designer asks is whether the noun is a thing the program needs to group other information or behavior around, or whether it is just a value that describes something else.
This flowchart is a reasoning aid written from the source's rule, not a formal procedure printed in the source. Use it to organize your thinking, and expect to revise the decision as the design develops.
Assigning Verbs to the Object They Act Upon
Verbs in a problem description are candidate instance methods. The key rule is that each verb belongs to the class of the object it acts upon. A method is not attached to the class because it sounds important; it is attached to the class whose objects it changes or reads. For the card game, shuffle and dealCard belong to Deck, and addCard and removeCard belong to Hand.
| Verb from the description | Object it acts upon | Candidate method on that class |
|---|---|---|
| shuffle | Deck | shuffle() |
| deal a card | Deck | dealCard() |
| add a card | Hand | addCard() |
| remove a card | Hand | removeCard() |
The same kind of question, which object does this action act on, sends each verb to a different class.
Card is described as relatively passive. It mostly holds information rather than acting on other things, so the description contains fewer obvious verbs for it. Even so, a program has to be able to find out a card's suit and value. That need suggests Card should offer methods that report those properties. The source notes that more instance methods will be discovered as the design develops, so a first list is expected to be incomplete.
Tracing How Card, Hand, and Deck Relate
With the candidate classes and methods identified, the next question is which object holds which. Both the Deck and the Hand contain many Card objects. The Deck holds the cards it deals from, and the Hand holds the cards that have been added to it. A Card holds its own suit and value, and the source does not give it a further role in this first design.
Read the diagram as a set of structural relationships. Deck and Hand each point to many Card objects. The arrows show ownership, not flow of control. The Card points to nothing else in this diagram, which matches the source's description of Card as a class that mostly holds information.
Why These Three Classes Are Worth Reusing
The source chooses Card, Hand, and Deck as its starting set because they are the most obviously reusable. A Card with a suit and value, a collection that cards can be added to and removed from, and a collection that can be shuffled and dealt from are ideas that a program can use again without change to their core purpose.
Mistakes When Scanning a Description
Common mistake Making every noun a class
What it looks likeCreating a class for suit and another for value, because both are nouns in the description.
Why it failsSuit and value are simple values that describe a card. The source says they are usually instance variables of Card.
Do this insteadAsk whether the noun groups other information or behavior. If it only describes another thing, keep it as an instance variable.
Common mistake Attaching a method to the wrong class
What it looks likePutting shuffle() on Hand because hands and decks both involve cards.
Why it failsA verb belongs to the class of the object it acts upon. Shuffling acts on the Deck.
Do this insteadFind the object that the verb changes or reads, and place the method on that object's class.
Common mistake Treating the first list as final
What it looks likeRefusing to add a method after the first pass, because the list already seems complete.
Why it failsThe source states that candidate lists are starting points and that more methods are discovered as the design develops.
Do this insteadRevisit the description and the design as the program takes shape, and expect to add methods.
Common mistake Skipping the phrase that justifies a decision, which makes later changes hard to explain
Practice: Scanning a New Description
A small library system is described as follows: a librarian checks books out to a member, and a member can return a book. Identify the candidate classes from the nouns, decide whether any simple values should be instance variables, and list the candidate methods by assigning each verb to the object it acts upon.
Hints
- Start with the nouns. Ask whether each one groups other things or only describes something else.
- For the verb check out, ask which object's state changes: the book, the member, or the librarian.
- Keep a note of the phrase that justifies each candidate so you can defend it later.
Key Takeaways
- Nouns in a problem description are candidate classes, such as Card, Hand, and Deck, and a designer starts with the most obviously reusable ones.
- Simple values such as suit and value are usually instance variables of a class like Card, not separate classes.
- Verbs are candidate instance methods, and each belongs to the class of the object it acts upon, such as shuffle and
dealCardfor Deck oraddCardandremoveCardfor Hand. - Candidate lists are starting points, so the design should be revisited as more methods are discovered.