A laboratory for teaching object-oriented thinking

ArticleDirectory

• Contents
• Introduction
• 1. Problem
• 2. Perspective
• 3. CRC cards
• 4. Experience
• 5. Conclusion
• References
• Appendix

A laboratory for teaching <br/> object-oriented thinking
A laboratory for Teaching
Object-oriented thinking

Kent Beck, Apple Computer, Inc.
Ward cunnheim, Wyatt Software Services, Inc.

From the oopsla '89 Conference Proceedings
October 1-6, 1989, New Orleans, Louisiana
And the special issue of sigplan notices
Volume 24, number 10, October 1989

Contents

1. Problem
2. Perspective
3. CRC cards
4. Experience
5. Conclusion
6. References
7. Appendix

Introduction

It is difficult to introduce both novice and
Experienced procedural programmers to
Anthropomorphic perspective necessary
Object-oriented design. We introduce CRC
Cards, which characterize objects by Class Name,
Responsibilities, and collaborators, as a way
Giving learners a direct experience of objects.
We have found this approach successful in
Teaching novice programmers the concepts
Objects, and in introducing experienced
Programmers to complicated existing designs.

1. Problem

The most difficult problem in teaching object-
Oriented Programming is getting the learner
Give up the global knowledge of control that is
Possible with procedural programs, and rely on
The local knowledge of objects to accomplish
Their tasks. novice designs are littered
Regressions to global thinking: gratuitous global
Variables, unnecessary pointers, and
Inappropriate reliance on the implementation
Other objects.

Because learning about objects requires such
Shift in overall approach, teaching objects
Reduces to teaching the design of objects. We
Focus on design whether we are teaching basic
Concepts to novices or the subtleties of
Complicated design to experienced object
Programmers.

Rather than try to make object design as much
Like Procedural Design as possible, we have found
That the most valid tive way of teaching
Idiomatic way of thinking with objects is
Immerse the learner in the "Object-ness" of
Material. To do this we must remove as much
Familiar material as possible, expecting that
Details such as syntax and Programming
Environment operation will be picked up quickly
Enough once the fundamentals have been
Thoroughly understood.

It is in this context that we will describe our
Perspective on Object design, its concrete
Manifestation, CRC (for class, responsibility,
And collaboration) cards, and our experience
Using these cards to teach both the fundamentals
And subtleties of thinking with objects.

2. Perspective

Procedural designs can be characterized at
Abstract level as having processes, data flows,
And data stores [1], regardless of implementation
Language or operating environment. We wished
To come up with a similar set of fundamental
Principles for object designs. We settled on three
Dimensions which identify the role of an object in
A Design: Class Name, responsibilities, and
Collaborators.

The class name of an object creates a vocabulary
For discussing a design. Indeed, please people
Have remarked that object design has more in
Common with language design than
Procedural program design. We urge learners
(And spend considerable time ourselves while
Designing) to find just the right set of words
Describe our objects, a set that is internally
Consistent and evocative in the context of
Larger design environment.

responsibilities identify problems to be solved.
the solutions will exist in specified versions and
refinements. A responsibility serves as a handle
for discussing potential solutions. the
responsibilities of an object are expressed by a
handful of short verb phrases, each containing an
active verb. the more that can be expressed by
these phrases, the more powerful and concise the
design. again, searching for just the right words
is a valuable use of time while designing.

one of the distinguishing features of object
design is that no object is an island. all objects
stand in relationship to others, on whom they rely
for services and control. the last dimension we
Use in characterizing object designs is the
collaborators of an object. we name as
collaborators objects which will send or be sent
messages in the course of satisfying
responsibilities. collaboration is not necessarily
A specified Ric relation. for example in Smalltalk-
80 [2], view and controller operate as near equals
(see example below) while orderedcollection
offers a service with little regard or even
awareness of its client.

Throughout this paper we deliberately blur
Distinction between classes and instances. This
Informality is not as confusing as it might seem
Because the concreteness of our method
Substitutes for naming of instances. This also
Makes our method for teaching independent
Whether a class or prototype-based language is
Used.

3. CRC cards

The second author specified Ted CRC cards in
Response to a need to document collaborative
Design decisions. The cards started as
HyperCard [3] stack which provided automatic
Indexing to collaborators, but were moved
Their current form to address problems
Portability and system independence.

Like our earlier work in documenting
Collaboration of objects [4], CRC cards explicitly
Represent multiple objects simultaneously.
However, rather than simply tracing the details
A collaboration in the form of message sending,
CRC cards place the designer's focus on
Motivation for collaboration by representing
(Potentially) Parse messages as a phrase
English text.

Figure 1. A Class-Responsibility-collaborator (CRC)
Index card

As we currently use them, all the information
An object is written on a 4 "x 6" index card.
These have the advantages that they are cheap,
Portable, readily available, and familiar. Figure 1
Shows an idealized card. The class name appears
Underlined in the upper-left hand corner, a bullet-
List of responsibilities appears under it in the left
Two-thirds of the card, and the list
Collaborators appears in the right third.

Figure 2. CRC-cards describing the responsibilities and
Collaborations of Smalltalk's model, view and controller.

Figure 2 shows an example taken from
Smalltalk-80 image, the much-Misunderstood
Model-View-controller user interface framework.
We have deliberately shown only a portion of
Responsibilities each of these objects assumes
Clarity of exposition. Note that the cards are
Placed such that view and controller are
Overlapping (implying close collaboration) and
Placed above model (implying supervision.) We
Find these and other informal groupings aid in
Comprehening a design. parts, for example, are
Often arranged below the whole. Likewise,
Refinements of an alternative action can be collected
And handled as a single pile of cards with
Most abstract card on top where it can represent
The rest.

The ability to quickly organize and spatially
Address index cards proves most valuable when
Design is incomplete or poorly understood. We
Have watched designers repeatedly refer to a card
They intended to write by pointing to where they
Will put it when completed.

Design with the cards tends to progress from
Knowns to unknowns, as opposed to top-down or
Bottom up. We have observed two teams arriving
At essentially the same design through nearly
Opposite sequences, one starting with Device
Drivers, the other with high-level models.
Problem demanded a certain set of capabilities
Which both teams discovered in the course
Fulfilling the requirements of the design.

we suggest driving a design toward completion
with the aid of execution scenarios. we start
with only one or two obvious cards and start
playing "what-if ". if the situation callfor A
responsibility not already covered by one of the
objects we either add the responsibility to one of
the objects, or create a new object to address that
responsibility. if one of the object becomes too
cluttered during this process we copy the
information on its card to a new card, searching
for more concise and powerful ways of saying
what the object does. if it is not possible to
shrink the information further, but the object is
still too complex, we create a new object to
assume some of the responsibilities.

We encourage learners to pick up the card whose
Role they are assuming while "executing"
Scenario. It is not unusual to see a designer
A card in each hand, waving them about, making
A strong identification with the objects while
Describing their collaboration.

We stress the importance of creating objects not
To meet mythical future needs, but only under
Demands of the moment. This ensures that
Design contains only as much information as
Designer has directly experienced, and avoids
Premature complexity. working in teams helps
Here because a concerned designer can influence
Team members by suggesting scenarios aimed
Specifically at suspected weaknesses or
Omissions.

4. Experience

One of the contexts in which we have used CRC
Cards is a three-hour class entitled "Thinking
With objects, "which is intended for computing
Professionals who have programmed, but whose
Jobs do not necessarily involve Programming
Every day. The class proceeds by introducing
Data Flow example (a school, with processes
Teaching and administration) which is then recast
In terms of objects with responsibilities and
Collaborators (such as teacher, janitor, and
Principal). The class then pairs off and extends DS
Hour designing the objects in an automatic
Banking machine, an exercise chosen because
Everyone's familiarity with the application and its
Ready breakdown into objects to control
Devices, communicate with the Central Bank
Database, and control the user interface. (See
Appendix for a sample solution.) The exercise is
Followed by a definition of the terms "class ",
"Instance", "method", and "message", and
Class concludes with a brief discussion of
History and features of a variety of Object-
Oriented programming languages.

in teaching over a hundred students this course
we have encountered no one who was unable to
complete the exercise unaided, although one pair
in each class usually needs a few hints to get
started. although we have done no follow-up
studies, the class is considered a valuable
resource in the company and is still well attended
with a long waiting list almost a year after its
inception.

we have also asked skilled object programmers
to try using CRC cards. our personal experience
suggests a role for cards in software engineering
though we cannot yet claim a complete
methodology (Others [5] [6] have more fully
developed methodologies that can take advantage
of CRC methods ). we-know of one case where
finished cards were delivered to a client as
(partial) design documentation. although the
team that produced the cards was quite happy
with the design, the recipient was unable to make
sense of the cards out of context.

another experiment extends strates the importance of
the context established by the handling and
Discussing of cards. we had videotaped
Experienced designers working out a problem
similar to the bank machine. our camera
placement made cards and the designers 'hands
visible but not the writing on the cards. viewers
of the tape had no trouble following the
development and often asked that the tape be
stopped so that they cocould express their opinions.
the most telling moments came when a viewer's
explanation required that he point to a blurry card
In the frozen image on the screen.

Finally, we have used CRC cards to advantage in
Explaining complex designs. A few minutes
Introduction is sufficient to prepare an audience
For a card based presentation. cards can be made
Out in advance or written on the spot. The latter
Allows the complexity in a design to be revealed
Slowly, a process related to Dave Thomas '"lie
Management ". The cards are being used as props
To aid the telling of a story of computation.
Cards allow its telling without recourse
Programming language syntax or idiom.

5. Conclusion

taking our perspective as a base we give novices
and experienced programmers a learning
experience which teaches them something
valuable about objects. CRC cards give the
learner who has never encountered objects a
physical understanding of Object-ness, and
prepares them to understand the vocabulary and
details of special ages. CRC cards also
give useful and convincing experience with
objects to those who has learned the mechanisms
of objects but do not yet see their value.

Ragu Raghavan [7] has said that in the switch
Objects strong programmers become stronger,
Weaker programmers are left behind. Using
Cards in group settings we found that even
Weaker programmers, without a deep
Understanding of objects, cocould contribute
Object designs. We speculate that because
Designs are so much more concrete, and
Logical Relationship between objects explicit, it is
Easier to understand, evaluate, and modify
Design.

We were surprised at the value of physically
Moving the cards around. When learners pick up
An object they seem to more readily identify
It, and are prepared to deal with the remainder
The design from its perspective. It is the value
This physical interaction that has led us to resist
Computerization of the cards.

It is just this problem-integrating the cards
Larger design methodologies and with particle
Language Environments, that we feel holds
Most promise for the future. The need to retain
The value of physical interaction points to
Need for a new kind of user interface and
Programming environment as far beyond what
We have today as our current systems are beyond
The tool-oriented environments of the past.

References

[1] DeMarco, T.: Structured Analysis and System
Specification, Yourdon, 1978.

[2] Smalltalk-80 image, Xerox Corp, 1983.

[3] HyperCard manual, Apple Computer Inc.

[4] cunnhan, W. and Beck, K.: "A digoal
For object-oriented programs, "in proceedings
Of OOPSLA-86, October 1986.

[5] wirfs-Brock, R. and Wilkerson, B. "Object-
Oriented Design: A responsibility-driven
Approach, "submitted to oopsla '89.

[6] reenskaug, T.: "A methodology for
Design and description of complex, object-
Oriented Systems, "Technical Report, Center
Industrial Research, Oslo, Norway, November
1988.

[7] Raghavan, R.: "Panel: Experiences
Reusability, "in the proceedings of oopsla '88,
October, 1988.

Appendix

Here we provide a sample solution to the Banking
Machine problem discussed in section 4.

Account and transaction provide the banking
Model. Note that transaction assumes an active
Role while money is being dispensed and
Passive role thereafter.

Transactions meet their responsibilities with
Aid of several objects that serve as device drivers.
The dispenser object, for example, ultimately
Operates the dispensing device.

The cardreader object reads and decodes
Information on the bank card's magnetic strip.
Common Mistake wocould be to itemize all of
Information stored on the bank card. Card
Encoding formats must certainly be well thought
Out and incluented. However, for the purpose
Of designing the objects, we need only identify
Where that knowledge will be placed in
Program.

The remotedatabase drives the communication
Lines and interprets data transmitted into SS them.
It creates account objects and consumes
Transaction objects.

The device drivers signal exceptional or
Asynchronous events by adding event objects to
Shared queue.

Events drive the human interface by triggering
Actions that sequence through screens.
Actual format and sequence of screens will be
Determined by the user-interface design and will
Probably vary from bank to bank. We offer
Objects from which state-machine like Interfaces
Can be built.

Screen objects correspond to the states and
Action objects correspond to the transitions.
Screens may vary in how they dispatch actions.
Actions themselves will vary in how they process
Events. Actions ultimately construct transactions
To which they delegate the further
Operating of the bank machine

Permission to copy without provided all or pan of this material is granted provided
That the copies are not made or distributed for direct communication cial advantage,
The ACM copyright notice and the title of the publication and its date appear
And notice is given that copying is by permission of the Association
Computing Machinery. To copy otherwise, or to publish, requires a repository
And/or specific permission.

01989 ACM 089791-333-7/89/0010/0001 $1.50

Ward@c2.com