CRC cards

CRC Cards


What are CRC cards? Are they really useful or just a waste of time? Why should I care? Where where were you on the night of December 25th? We all have asked these questions to ourselves at least once in our lives. And I’ll just answer the first one.

CRC (stands for Class, Responsibility and Collaboration) cards (stands for Community Assistance for Reconstruction, Development, and Stabilisation) is an Object Oriented design pattern, useful.

These cards are supposed to help the software developer to think which objects he will need to have, what methods they will have and how will they interact among them, even before start writing code. It is supposed to be a good tool to learn the OOP paradigm because, regardless the syntax or implementation of an specific language, you can focus in what really matters, the whole concept of objects.

To write CRC cards you need to think about three things:

  1. Class (name):The class has to have a short and descriptive name of what it represents and what it does.
  2. Responsibility:
    The problems that the class is supposed to solve and its procedures, these should be short verb phrases containing an active verb. This is typically what this class does when it interacts with other classes.
  3. Collaboration:
    Objects should not be isolated from each other, they all must collaborate to accomplish a common goal, just like we learned from The Wonder Pets! Here you write with which other classes this one interacts with.

CRC cards have the following format and are written in 4×6 index cards:

With CRC cards you can clearly see the relationship between classes, and the index cards have the advantage that you can move them around, organize and overlap them so you can put them in certain position that helps you to think about the relationship between these classes.

And with this I answer to the fist question, you should be able to answer the second and third questions by yourself, maybe the fourth too.

Information and images extracted from

Permission to copy without fee all or pan of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to publish, requires a fee and/or specific permission.

Overloading vs. Overriding


Serendigity. “Overload” Online Image. Flickr. Octover 3, 2007.

Overloading and overriding are two similar concepts -they both are about creating several methods with the same name- but very different when it comes to practical functionality and implementation.

Overloading (formally, static polymorphism) is resolved at compile time, and it is when the methods with the same name are declared in the same class, distinguished only by their signatures (the parameters of the method), so that the compiler knows which method overload you are calling based on the data type of the arguments you are passing.

Overriding (or overwriting, according to ken), is resolved at runtime and it is when you define a method that is already defined in a parent class. It can be resolved because of the data type of the “implicit first parameter” (aka, the object itself).

Java implementation



Overloading with different data types and number of parameters.


Overloading with same data types and number of parameters, but different order.


Overloading allow different return types.


The return type of the method is not considered when overloading.



In this example of overriding I have the Person abstract class, this class cannot be instantiated, but it provides like a “template” for its children classes. For example, the Person class has a String field “name”, because every person has a name, and a public method “talk” because all persons can talk (ok, almost all), this method prints “I’m a ” to the console, because, like I said, this is like a template, and different persons have different (very interesting) things to say. The method “getName” returns the name of the person. The constructor just takes the String name, although you can’t call this constructor directly, it can be called from its children classes.

It’s children classes are not abstract and extend (are children of) the Person class. They implicitly have “name”, a method “talk” and a method “getName”. Read the code of the Student and the Teacher classes and note how the constructors have a line “super(name)”, this is a call to the parent class constructor, and it will throw an error if it’s not there. Both the Student and the Teacher class Override the talk method, the notation @Override over the talk method just tells the compiler that you are overriding a method (no shit, Sherlock), it’s not required but you should use it to enforce proper overriding of a method. The talk() methods of Student and Teacher call the “” method (unlike the constructor, you can miss this statement here and there will be no errors), it prints “I’m a “, and then it prints something else. I also included an Overload of an Overriding method (mind blown) in the Student class to show the difference, it just prints “I love” + the argument (there is no call to

In the main method of the Person class I declare 2 persons, one teacher and other student, also, I declare a Student as a Student, this sound stupid but actually affects in the code. The preferred way is to declare the variable with the data type of the abstract class and instantiate it as the type that you actually want to use (Declared type on the left  and Actual type on the right so your code is not dependent from a specific implementation of an interface/abstract class. You can read more about this here. You can see that when the talk method is called from both the teacher and the student they print different things. Finally, to call the Overload method “talk(String food)” of “s” (with Declared type Person and Actual type Student) you have to implicitly cast it to Student and then call the method, like ((Student)s).talk(“tacos”), this is because this implementation is not declared in the Declared type of “s”. However, with “c” this does not happen, you can call that overload method because the Declared type of “c” is Student. Anyway, this is not considered a good OO practice, you should avoid writing methods that are not in the parent class, because there is a method specific to the Children class, and therefore making the code dependent from that class, and what you want is to make the code independent from specific implementations of the children classes (like explained in the previous stack overflow link).