The
Object Game
An Exercise for Studying Objects
Joseph Bergin
Pace University
jbergin@pace.edu
http://csis.pace.edu/~bergin
At the beginning of a first course in object oriented programming or design the students need a vivid demonstration of what objects are and how they interact. This page describes a classroom activity for the instructor and a group of students that will put the students into the right frame of mind for studying objects.
The instructor needs to do some preparation prior to the game. Here I will detail an ideal situation, but you may decide to use only some of this.
First you must pick some problem and design two solutions, a good one and one less appropriate. The problem should be generally known to the students and the operation of the real system should be familiar to them. Examples are vending machines, ATM machines, CD changers and the like. The problem and solution can be quite simple, but it should have several classes and at least one of the classes should require multiple instantiations. You will need a problem so that the number of required objects is not greater than the number of students in your class. If this is impossible, you will need to recruit a few volunteers from outside your class for this exercise.
It is also helpful to have a set of name tags, perhaps the kind with sticky backs, on which you can write the reference names of the various objects (not the class names) in your system. These will eventually be worn by the players.
One of your solutions should be very clear and clean and the other should have one or more obvious flaws. An easy flaw in many solutions is to have a class with too many responsibilities. Such a class forms a communication bottleneck and usually a logic bottleneck making maintenance difficult.
Prepare sets of CRC cards for each of your solutions. For any class requiring multiple instantiations, prepare multiple cards. Prepare an Object Diagram showing the communication paths allowed by the objects. Put this on an overhead slide or be prepared to copy it to a black/white board at the beginning of the game. Technically this isn't needed, but it can be a handy reference.
Select a number of students equal to the number of objects required for the GOOD solution. Give each one of them a CRC card and an object name by which they can be referenced by the other "objects". They can wear a tag with that object name so the other "objects" will be able to find them easily. Give all of them instructions about what they are allowed to do and say. In essence, they can respond to any message matching a service (responsibility) named on their card. If they don't have the information available to respond to the request directly, they can make a request of another object according to the Object Diagram. The name of the objects that they make request of are also be on the CRC card as the collaborators. Each person (object) may need a pencil and paper to record information about their state.
The instructor has several roles and so should not be one of the players. The first role is to act as the external actor in the system, requesting some service. The next is to make sure that the rules are followed and that communication only goes along the specified paths in the Object Diagram. Finally, the instructor can comment on the process and especially on any awkward information flows that are recognized.
The instructor initiates one play of the game by requesting some service of some appropriate (interface) object in the system. That object (person) interacts with the other objects according to the rules to provide the required service.
After a few plays (at least two) the instructor can give a few comments.
Repeat the above, using the other solution that had the flaws. As the game is played, comment on the consequences of the flaw.
This game should give the students an appropriate mental model of objects. Objects are active. Objects provide services. Objects request services. Objects do only what they are designed to do. Computation occurs through interaction. Objects of the same class behave similarly, but their internal "state" also determines the effect of a service request.
After the game is played, the students should be able to create Sequence Diagrams (UML) for the system, since they have just acted out these sequences of interactions. They can do this as a joint project, with the person playing each class contributing the interactions of objects of that class.
You can discuss object oriented design prior to this exercise or not. You can use it as an introduction to design or not. If you use it as an introduction you can then show the students your design using UML or other notation. You can actually use such an exercise on the first day of class, prior to any discussion of objects. This might be advantageous if you want to use many such "active " in-class exercises in the course of the term.
I use this game following a Student Design Sprint (Pedagogical Pattern) on a coffee machine. It is therefore not done on the first day, as there has been some introduction to CRC and to UML. The coffee machine exercise has been detailed elsewhere. It was created by Alistair Cockburn. The good solution requires about five classes with only the Dispenser class being multiply instantiated.
This game is actually a complex metaphor and it is quite good at eliciting the right mind set. However, like most metaphors it has a limitation that will need to eventually be spelled out to the students. Since the "objects" wear their names, it will seem like the name is an inherent part of the object, when in fact this is not the case. A reference (variable) can refer to any object of the appropriate type. It might be good to be explicit about this difference at some point, though not necessarily as the game proceeds. The distinction between an object and a variable that is used to refer to it is an important one that is clouded by this exercise.
Coffee Machine Part 1 (Cockburn) Or at Alistair's Site
Coffee Machine Part 2(Cockburn) Or at Alistair's Site
Pedagogical Patterns (Bergin)
CRC Cards (Cunningham and Beck)
Last Updated: November 10, 2006