Page 527 - Introduction to Programming with Java: A Problem Solving Approach

12.10 Design Practice with Card Game Example 493
Dealership and DealershipDriver classes defined in Figures 12.3 and 12.7, respectively, except Dealership is changed to Dealership2, Manager is changed to Manager2, and SalesPerson is changed to SalesPerson2.
In Figure 12.14, the addition of the Person class makes it look like we made the Dealership2 program bigger by adding another class. But the additional Person class was already defined in another program, the Person/Employee/FullTime program. In borrowing the Person class from that program, we got some- thing for nothing. The borrowed Person class enabled us to shorten two other classes. Being able to bor- row classes that have already been written and then inheriting from them in other contexts is an important benefit of OOP. If you look at the prewritten classes in the Java API, you’ll see that they do a lot of inheriting from one to another, and in many cases, you have the option of inheriting from them into your own pro- grams, as well.
12.10 Design Practice with Card Game Example
In the previous section, you learned how to use different types of class relationships together in a single pro- gram. The way you learned was by adding inheritance to an existing program. In this section, you’ll once
again use different types of class relationships, but this time you’ll design the program from the ground up. And you’ll be doing most of the work, rather than just understanding how it’s done by someone else.
Your Mission (Should You Choose to Accept It)
Apago PDF Enhancer
Learn by doing.
Your mission is to design and implement a generic card game program. In carrying out this mission, follow these guidelines:
• Assume it’s a game like war or gin rummy where you have a deck of cards and two players.
• Decide on appropriate classes. For each class, draw a UML class diagram and write in the class name.
• Look for composition relationships between classes. For each pair of classes related by composition,
draw a compositional association line with appropriate multiplicity values.
• For each class, decide on appropriate instance variables.
• For each class, decide on appropriate public methods.
• Look for common instance variables and methods. If two or more classes contain a set of common
instance variables and methods, provide a superclass and move the common instance variables and methods to the superclass. The classes originally containing common members now become subclasses of the superclass. For each subclass-superclass pair, draw an association line with an inheritance arrow from the subclass to the superclass to indicate an inheritance relationship.
Now go ahead and use the above guidelines to draw a UML class diagram for a generic card game pro- gram. Since this is a non-trivial exercise, you may be tempted to look at our solution before trying to come up with a solution on your own. Please resist that temptation! By implementing your own solution, you’ll learn more and make yourself aware of potential problems.
Defining the Classes and the Relationships Between Them
Have you finished your class diagram? If so, then you may continue. . . .
In coming up with a class diagram, the first thing to do is to decide on the classes themselves. Unfortu-
nately, that’s a bit of an art. The easy classes are the ones that directly correspond to something you can see.