- [Man] One technique that can be useful during this stage of Object Oriented Design are CRC cards. Which stands for: Class, Responsibility, Collaboration. CRC cards contain the same information as the Conceptual Object Diagram, just in a different format. They're drawn on index cards, and they're meant to be simple. Easy to create, hand around, discuss, spread out on a conference table, and you dispose of it if you make a mistake, or change your mind. Each CRC cards represents one class, and it has three sections.
The first C is the name of the class at the top, which is usually underlined. The R is the Responsibilities of the class, the things that it needs to take care of. And the second C is for the Collaborators, the other classes it interacts with. CRC cards typically use this format with the responsibilities taking up the left two-thirds of the card, and the collaborators on what's remaining to the right. You may also hear these referred to as CRH cards for: Component, Responsibilities, and Helper.
Those are effectively the same thing, just using different terms. Start creating these cards by using the nouns, and your use case and user story descriptions, to help identify potential classes, and the verbs, and verb phrases, to help identify responsibilities. - [Woman] So a card to represent our Missile class could have things like: Fly through space, Destroy asteroid, and Disappear offscreen, as responsibilities. I'm not worried about the official method names here, I'm just using whatever phrases makes sense to say what this class needs to do.
We can refine these later. Some will be combined and some will split apart. If it's obvious which of the other classes will be Collaborators. Meaning what other classes will interact with this one, then I can write those too. I know this Missile class will interact with the spaceship that fires it, the play area it flies through, and the asteroid it blows up. So I'll add those to the right hand side. - [Man] One of the great things about CRC cards is that when you physically start to do this, and start creating a pile of cards, most people naturally find themselves moving related 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 jump to using an electronic tool for doing this, because there's a lot of value in the physicality of moving things around. - [Woman] Using physical cards also enforces a constraint. You can keep adding more and more index cards to your collection, but, if you need more than one CRC card for a single class, that's a clue that you may need to redesign that class, because, you're trying to give it too much responsibility.
Whether you choose to use CRC cards, or a Conceptual Diagram, or some other method of your own. You should finish this phase of the object oriented design process, with at least the names and core responsibilities for the first set of classes you intend to code.
- Object-oriented basics: objects, classes, and more
- Defining requirements
- Identifying use cases, actors, and scenarios
- Domain modeling
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Developing software with object-oriented design principles