CSC/ECE 517 Fall 2007/wiki2 5 kq: Difference between revisions
| Line 46: | Line 46: | ||
* [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989] | * [http://c2.com/doc/oopsla89/paper.html#cards Paper of Beck & Cunningham 1989] | ||
* [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995] | * [http://www.ambysoft.com/books/theObjectPrimer.html Book of Ambler 1995] | ||
* [http://www.c2.com/cgi/wiki?CrcCard CRC Card] | |||
* [http://courses.knox.edu/cs292/ATMExample/index.html An Example of Object-Oriented Design: An ATM Simulation] | |||
Revision as of 20:27, 20 October 2007
This Wiki Page is edited by Kunta Tsai and Qinyi Ding
Topic
CRC cards. Hundreds of Web pages cover CRC cards. Which explain them best? Which explain them in the context of specific languages, e.g., Ruby and Java? Which exercises can be used to teach them best, (i) interactively over the Web, (ii) to a class of students, via in-class exercises, (iii) for self-study?
Definition
A Class Responsibility Collaborator (CRC) model (Beck & Cunningham 1989; Wilkinson 1995; Ambler 1995) is a collection of standard index cards that are used when first determining which classes are needed and how they will interact. A CRC card always contain these sections:
- The class name: represents a collection of similar objects
- Its Super and Sub classes (if applicable)
- The responsibilities of the class: represents something a class knows or does
- The collaborator: The names of other classes with which the class will collaborate to fulfill its responsibilities.
- Author
An example of CRC card is shown in figure 1.
Figure 1
Advantages of CRC Card
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.
A common method to determine what cards should be created is to read a specification for the program being designed and consider if each noun should be a class and if each verb should be a responsibility of the noun or class to which it belongs. Naturally, the existence of a noun or verb does not require a class or responsibility in the program, but it is considered a good starting point.