DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • The SPACE Framework for Developer Productivity
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
  • Observability Architecture: Financial Payments Introduction

Trending

  • The SPACE Framework for Developer Productivity
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
  • Observability Architecture: Financial Payments Introduction

CRC Cards - Naming Part 3

Roger Hughes user avatar by
Roger Hughes
·
Jun. 11, 12 · Interview
Like (1)
Save
Tweet
Share
5.81K Views

Join the DZone community and get the full member experience.

Join For Free
Another way of specifying a class’s name is to use CRC cards. Proposed by Kent Beck and Ward Cunningham1, I first came across these many years ago in Grady Booch’s book ‘OO Analysis and Design’. CRC initially stood for Class, Responsibilities and Collaborators, though in today’s single responsibility principal world, Responsibilities has been quietly renamed Responsibility. The concept is that you use the cards as part of your design process to determine your system’s key abstractions and their relationships. To use CRC cards, first you need a bunch of... well... cards. The 3 x 5 inch index cards will do. You then divide the card up as shown below:


From the diagram you can see that the card is divided into three areas: the name of the class is prominently placed along the top of the card, its responsibility in the centre and the collaborators that’ll help to fulfill that responsibility at the bottom. This is just my personal preference for laying out a CRC card - I find it easier to fit the text in this way. The original authors split the card vertically and not horizontally as I do.


Note the the original CRC card design only ever contained the three fields: Class, Responsibilities and Collaborators; however, if you look on Wikipedia an additional two fields have been added by the author: SubClasses and SuperClass. Whilst specifying a class’s superclass may be useful, I disagree with adding subclasses. This is because an object should know nothing about its subclasses and its design shouldn’t be influenced by them. Furthermore adding extra information will tend to hide the main benefit of CRC cards.

According to proponents of CRC cards, they’re useful because they allow you map out your application’s design before jumping straight into coding, which is always a good idea. This has the benefit that in mapping a class on a card you’re easily able to discover other classes within your application. Cards can be shuffled, laid out or pinned to walls to outline your application’s key abstractions.


In the example above I’ve written the cards for a scenario where the user has to add their address to the system. This is a simple MVC scenario to demonstrate the relationship between cards/classes.

The next question to ask is are CRC cards still useful or obsolete; after all they are now twenty two years old. I have to say that they probably aren’t that useful; however, they do seem to get mentioned in a good number of OO design books and are popular on the web. If you Google “CRC Cards” you’ll get 7,540,000 results, but have you ever seen any one using them in anger?

I have to stick my hand up now and say that I have in the past CRC cards. You don’t, however, have to use 3 x 5 inch index cards as there is a lot of benefit in simply scribbling out the CRC headings in your note book and adding the responsibility and collaborators next to them. All of which means that it’s now time to reveal a big secret... the cards themselves aren’t really that useful; the most important and useful thing about these cards is the fact that you’re forced to think about and write down an object’s responsibility. This stands to reason: if you can’t define your object’s intent, how can you code it?

Having accurately defined a class's responsibility you now know exactly what it does and why it exists and can therefore review the original name that you chose and, if necessary, come up with something more suitable.

The idea of constantly reviewing the name of a class and comparing it with its responsibility is the key to good object naming.

So, the next question to ask is whether or not there are any guidelines for defining an object’s responsibility? There are, but more on that next time.
California Report Card Cards (iOS)

Published at DZone with permission of Roger Hughes, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • The SPACE Framework for Developer Productivity
  • Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
  • A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
  • Observability Architecture: Financial Payments Introduction

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: