CRC Cards - Naming Part 3
CRC Cards - Naming Part 3
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
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.
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.
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.
Published at DZone with permission of Roger Hughes , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.