📄 a laboratory for teaching object-oriented thinking.mht
字号:
From: <由 Microsoft Internet Explorer 5 保存>
Subject: A Laboratory For Teaching Object-Oriented Thinking
Date: Thu, 12 Mar 2009 14:13:50 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----=_NextPart_000_0039_01C9A31C.C43BB970"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
This is a multi-part message in MIME format.
------=_NextPart_000_0039_01C9A31C.C43BB970
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://c2.com/doc/oopsla89/paper.html
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>A Laboratory For Teaching Object-Oriented =
Thinking</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY bgColor=3Dwhite>
<H1>A Laboratory For Teaching <BR>Object-Oriented Thinking </H1><I>Kent =
Beck,=20
Apple Computer, Inc.<BR>Ward Cunningham, Wyatt Software Services, Inc. =
</I>
<P><FONT size=3D-3><I>From the OOPSLA'89 Conference Proceedings =
<BR>October 1-6,=20
1989, New Orleans, Louisiana <BR>And the special issue of SIGPLAN =
Notices=20
<BR>Volume 24, Number 10, October 1989 </I></FONT>
<P>
<H3>Contents</H3>
<OL>
<LI><A =
href=3D"http://c2.com/doc/oopsla89/paper.html#problem">Problem</A>=20
<LI><A=20
=
href=3D"http://c2.com/doc/oopsla89/paper.html#perspective">Perspective</A=
>=20
<LI><A href=3D"http://c2.com/doc/oopsla89/paper.html#cards">CRC =
Cards</A>=20
<LI><A =
href=3D"http://c2.com/doc/oopsla89/paper.html#experience">Experience</A> =
<LI><A =
href=3D"http://c2.com/doc/oopsla89/paper.html#conclusion">Conclusion</A> =
<LI><A =
href=3D"http://c2.com/doc/oopsla89/paper.html#references">References</A> =
<LI><A =
href=3D"http://c2.com/doc/oopsla89/paper.html#appendix">Appendix</A>=20
</LI></OL>
<P>
<H3>Introduction</H3>It is difficult to introduce both novice and =
experienced=20
procedural programmers to the anthropomorphic perspective necessary for=20
object-oriented design. We introduce CRC cards, which characterize =
objects by=20
class name, responsibilities, and collaborators, as a way of giving =
learners a=20
direct experience of objects. We have found this approach successful in =
teaching=20
novice programmers the concepts of objects, and in introducing =
experienced=20
programmers to complicated existing designs. <A name=3Dproblem>
<H3>1. Problem</H3></A>The most difficult problem in teaching object- =
oriented=20
programming is getting the learner to give up the global knowledge of =
control=20
that is possible with procedural programs, and rely on the local =
knowledge of=20
objects to accomplish their tasks. Novice designs are littered with =
regressions=20
to global thinking: gratuitous global variables, unnecessary pointers, =
and=20
inappropriate reliance on the implementation of other objects.=20
<P>Because learning about objects requires such a shift in overall =
approach,=20
teaching objects reduces to teaching the design of objects. We focus on =
design=20
whether we are teaching basic concepts to novices or the subtleties of a =
complicated design to experienced object programmers.=20
<P>Rather than try to make object design as much like procedural design =
as=20
possible, we have found that the most effective way of teaching the =
idiomatic=20
way of thinking with objects is to immerse the learner in the =
"object-ness" of=20
the material. To do this we must remove as much familiar material as =
possible,=20
expecting that details such as syntax and programming environment =
operation will=20
be picked up quickly enough once the fundamentals have been thoroughly=20
understood.=20
<P>It is in this context that we will describe our perspective on object =
design,=20
its concrete manifestation, CRC (for Class, Responsibility, and =
Collaboration)=20
cards, and our experience using these cards to teach both the =
fundamentals and=20
subtleties of thinking with objects. <A name=3Dperspective>
<H3>2. Perspective</H3></A>Procedural designs can be characterized at an =
abstract level as having processes, data flows, and data stores <A=20
href=3D"http://c2.com/doc/oopsla89/paper.html#references">[1]</A>, =
regardless of=20
implementation language or operating environment. We wished to come up =
with a=20
similar set of fundamental principles for object designs. We settled on =
three=20
dimensions which identify the role of an object in a design: class name, =
responsibilities, and collaborators.=20
<P>The class name of an object creates a vocabulary for discussing a =
design.=20
Indeed, many people have remarked that object design has more in common =
with=20
language design than with procedural program design. We urge learners =
(and spend=20
considerable time ourselves while designing) to find just the right set =
of words=20
to describe our objects, a set that is internally consistent and =
evocative in=20
the context of the larger design environment.=20
<P>Responsibilities identify problems to be solved. The solutions will =
exist in=20
many versions and refinements. A responsibility serves as a handle for=20
discussing potential solutions. The responsibilities of an object are =
expressed=20
by a handful of short verb phrases, each containing an active verb. The =
more=20
that can be expressed by these phrases, the more powerful and concise =
the=20
design. Again, searching for just the right words is a valuable use of =
time=20
while designing.=20
<P>One of the distinguishing features of object design is that no object =
is an=20
island. All objects stand in relationship to others, on whom they rely =
for=20
services and control. The last dimension we use in characterizing object =
designs=20
is the collaborators of an object. We name as collaborators objects =
which will=20
send or be sent messages in the course of satisfying responsibilities.=20
Collaboration is not necessarily a symmetric relation. For example in =
Smalltalk-=20
80 <A href=3D"http://c2.com/doc/oopsla89/paper.html#references">[2]</A>, =
View and=20
Controller operate as near equals (see example below) while =
OrderedCollection=20
offers a service with little regard or even awareness of its client.=20
<P>Throughout this paper we deliberately blur the distinction between =
classes=20
and instances. This informality is not as confusing as it might seem =
because the=20
concreteness of our method substitutes for naming of instances. This =
also makes=20
our method for teaching independent of whether a class or =
prototype-based=20
language is used. <A name=3Dcards>
<H3>3. CRC Cards</H3></A>The second author invented CRC cards in =
response to a=20
need to document collaborative design decisions. The cards started as a=20
HyperCard <A =
href=3D"http://c2.com/doc/oopsla89/paper.html#references">[3]</A>=20
stack which provided automatic indexing to collaborators, but were moved =
to=20
their current form to address problems of portability and system =
independence.=20
<P>Like our earlier work in documenting the collaboration of objects <A=20
href=3D"http://c2.com/doc/oopsla89/paper.html#references">[4]</A>, CRC =
cards=20
explicitly represent multiple objects simultaneously. However, rather =
than=20
simply tracing the details of a collaboration in the form of message =
sending,=20
CRC cards place the designer's focus on the motivation for collaboration =
by=20
representing (potentially) many messages as a phrase of English text.=20
<P><IMG src=3D"http://c2.com/doc/oopsla89/fig1.gif"><BR><I>Figure 1. A=20
Class-Responsibility-collaborator (CRC) index card </I>
<P>As we currently use them, all the information for an object is =
written on a=20
4" x 6" index card. These have the advantages that they are cheap, =
portable,=20
readily available, and familiar. Figure 1 shows an idealized card. The =
class=20
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=20
list of collaborators appears in the right third.=20
<P><IMG src=3D"http://c2.com/doc/oopsla89/fig2.gif"><BR><I>Figure 2. =
CRC-cards=20
describing the responsibilities and collaborations of Smalltalk's Model, =
View=20
and Controller.</I>=20
<P>Figure 2 shows an example taken from the Smalltalk-80 image, the=20
much-misunderstood model-view-controller user interface framework. We =
have=20
deliberately shown only a portion of the responsibilities each of these =
objects=20
assumes for clarity of exposition. Note that the cards are placed such =
that View=20
and Controller are overlapping (implying close collaboration) and placed =
above=20
Model (implying supervision.) We find these and other informal groupings =
aid in=20
comprehending a design. Parts, for example, are often arranged below the =
whole.=20
Likewise, refinements of an abstraction can be collected and handled as =
a single=20
pile of cards with the most abstract card on top where it can represent =
the=20
rest.=20
<P>The ability to quickly organize and spatially address index cards =
proves most=20
valuable when a design is incomplete or poorly understood. We have =
watched=20
designers repeatedly refer to a card they intended to write by pointing =
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -