Using CRC cards
Video: Using CRC cardsHere is an alternate technique commonly found at this stage of an Object-Oriented Design: CRC Cards. CRC stands for Class, Responsibility, Collaboration. Now we're looking for exactly the same information as in the conceptual object diagram, we're just using a different format, and these are another use of index cards, they're simple, they're easy to create, easy to discuss, hand around, spread across the conference table, and they're easy to dispose of if you make a mistake or change your mind. Each CRC card represents one class.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Using CRC cards
Here is an alternate technique commonly found at this stage of an Object-Oriented Design: CRC Cards. CRC stands for Class, Responsibility, Collaboration. Now we're looking for exactly the same information as in the conceptual object diagram, we're just using a different format, and these are another use of index cards, they're simple, they're easy to create, easy to discuss, hand around, spread across the conference table, and they're easy to dispose of if you make a mistake or change your mind. Each CRC card represents one class.
It has three sections, the first C is the name of the class at the top, usually underlined, the R is the responsibilities of the class, the things that needs to take care of, and C is the Collaborators, the other classes it interacts with. Typically, CRC cards use this format with the responsibilities in the left-hand side two-thirds of the card, and the collaborators on what's remaining on the right. And you can start creating these again from using the nouns in your descriptions to help you identify classes, and the verbs and verb phrases to help you identify say the first responsibilities.
Now, with these responsibilities, you're not worried about official method names, you're just using whatever phrases make sense to say what this class needs to take care of. You can refine these later, some will be combined, some will be split apart. If it's obvious what other classes you're writing are collaborators, meaning what other classes we interact with, you can write those too. But here is the great thing, when you physically start to do this and start creating a pile of CRC cards, most people naturally find themselves starting to move related CRC cards together, and that helps a lot in figuring out the natural collaborators and the way these objects interact.
And that's one reason you shouldn't look for an electronic tool for doing this, it's a place where there is a lot of value in the physicality of moving these around, and as an exercise for helping you think in objects, CRC cards can be very useful. When working through CRC exercises, I've seen people rearrange these cards on a desk and then point to the gap where they're going to put this new class they haven't written yet. The other benefit of using the cards is an enforced constraint. As with using index cards for user stories, you can just keep adding more and more to these.
If you need more than one CRC card for a class, particularly if you're using 4 inch by 6 inch index cards, it's a clue that you may need to redesign that class. But whether you use CRC cards, conceptual diagrams, or a method of your own choosing, you should be able to leave this phase of the design process with at least the names and the core responsibilities of the first set of classes you intend to build in code. But before we start writing, we do need to flesh those ideas out, and that's next.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.