Day 7: Give Only One Responsibility to Each Class

Hi, this is the 7th part of a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.

One of the easiest ways to design software is to use the responsibility of each class as a guiding tool to improve your code. However, few people use this simple technique to create truly outstanding software.

The single responsibility principle (SRP) is a software development principle that states that each class should have one and only one major responsibility in the system. Any class with more than one major responsibility should be broken up into smaller classes (we can also merge together classes that do the same thing). Another definition, from wikipedia.org/wiki/Single_responsibility_principle:

“… the single responsibility principle states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.”

Let us first understand why this works, and then how we can use the single responsibility principle (SRP) in practice.

Reasons Why the SRP works

The main reason is that giving a single responsibility for each class is just a compact way of describing object orientation. Let us try to describing object oriented code through the lights of the SRP:

Methods are associated to a class because they have something to do with that class. If a class has too many responsibilities, the methods there have no reason to exist inside the class. So, the idea that objects have associated methods makes sense only if the SRP is used.
Polymorphism is necessary because classes in the same hierarchy respond to messages in different ways. However, this is possible only if there is a standard set of messages that make sense for a class. The SRP says that each class in the hierarchy must have a single purpose, and this purpose is defined by how they answer to a specific message, by its polymorphism.

Moreover, giving a class a single responsibility is a great way of defining the scope of a class. Instead of piling methods together, you are just looking for a functionality set that go together well.

How to Apply the SRP in Practice

The easy answer for that is just: refactoring! First, go through your design and try to identify the responsibility of each class. The way I like to do this is to create a comment on the top of each class starting like this: “this class is responsible for …”

If you cannot state in a few words what the responsibility of the class is, then you are probably doing too much.

Another clue is given by abstract descriptions like: “this class is a manager for …”. Such descriptions hide the fact that a class has no focus. Try to give a better description of what this class does, or change it to improve its focus.

About the Author

Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.

Published on July 1st, 2009

3 Responses to “Day 7: Give Only One Responsibility to Each Class”

Hmm… we sometimes must break this rule!
Because we can make fragment w/ this since we’re dividing reponsibility to many class!

By kureikain on Jul 4, 2009
Most of the programmer who came from the procedural language background, usually do this mistake: the stuff all their business into a single method/class.

But, in the long run, this mistake will turn into nightmare for the maintainer.

By Veera on Jul 4, 2009