Cunningham's CRC for OOD training

做开发的恐怕没有人不知道“面向对象”这个词，虽然对其不感冒的人也是有的，但毕竟是极少数，大部分程序员还是极力拥抱“面向对象”的。您要是指责某人不懂“面向对象”，非跟你急不可。

对于“面向对象”的特性和特征，大部分人应该还是说的上来的，但要说动手练练，那又是另外一回事了，“挂羊头卖狗肉”者大有人在，即用“面向对象”语言写着“过程式”程序，还一口咬定“我这就是货真价实的‘面向对象’，假一赔十！……”

其实，这也不能怨这些人，老师就这么教的，即使老师没有这么教，也没有说不能这样做，国内教科书也一样，简单堆砌了一些概念就以为“面向对象”结束了，结果的确学会了“类”、“成员变量”、“方法”……并且也能和以前用“过程”语言（如C语言）一样写出程序来，一样能跑通，于是简历上就加了一项“精通面向对象程序开发……”

曾经也经历过这个阶段，还用这种方式写出不少代码，这些代码还进入了正式系统 -_-!

最终的迷途知返是因为看了一些国外牛人的书，再加上之前摸爬滚打过程中的体验，才在“原来如此！”的惊叹中明白自己原来根本没有懂过“面向对象”，继而庆幸这些没有白读。

如下是一篇OOD文章中的片段，其中有一部分介绍了如下的CRC面向对象设计教学法，眼睛为之一亮：“今儿这文章没白读”

In 1989, Kent Beck and Ward Cunningham taught classes on OO design, and they had problems getting people to abandon the get/set mentality. They characterized the problem as follows:

The most difficult problem in teaching object-oriented programming is getting the learner to 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 with regressions to global thinking: gratuitous global variables, unnecessary pointers, and inappropriate reliance on the implementation of other objects.

Cunningham developed a teaching methodology that nicely demonstrates the design process: the CRC (classes, responsibilities, collaboration) card. The basic idea is to make a set of 4x6 index cards, laid out in three sections:

• Class: The name of a class of objects.
• Responsibilities: What those objects can do. These responsibilities should focus on a single area of expertise.
• Collaborators: Other classes of objects that can talk to the current class of objects. This set should be as small as possible.

The initial pass at the CRC card is just guesswork—things will change.

Beck and Cunningham then picked a use case and made a best guess at determining which objects would be required to act out the use case. They typically started with two objects and added others as the scenario played out. They selected people from the class to represent those objects and handed them a copy of the associated CRC card. If they needed several objects of a given class, then several people represented those objects.

The class then literally acted out the use case following these rules:

• Perform the activities that comprise the use case by talking to one another.
• You can only talk to your collaborators. If you must talk to someone else, you should talk to a collaborator who can talk to the other person. If that isn't possible, add a collaborator to your CRC card.
• You may not ask for the information you need to do something. Rather, you must ask the collaborator who has the information to do the work. It's okay to pass to that collaborator information he needs to do the work, but keep this interaction to a minimum.
• If something needs to be done and nobody can do it, create a new class (and CRC card) or add a responsibility to an existing class (and CRC card).
• If a CRC card gets too full, you must create another class (CRC card) to handle some of the responsibilities. Complexity is limited by what you can fit on a 4x6 index card.

A recording made of the entire conversation is the program's dynamic model. The finished set of CRC cards is the program's static model. With many fits and starts, you can solve just about any problem this way.