SOLID Principles #1: Single Responsibility Principle

In each part I will describe and analyze one of these principles. In the last part, expect summary of the entire series containing a few tips and thoughts.

Let’s start. What are SOLID Principles? There are five general design principles of object-oriented programming intended to make software more understandable, extendable, maintainable and testable.

1. Single responsibility principle (SRP)

2. Open/closed principle (OCP)

3. Liskov Substitution Principle (LSP)

4. Interface Segregation Principle (ISP)

5. Dependency Inversion Principle (DIP)

Today, more about first principle - Single Responsibility Principle.

Single Responsibility Principle

“Class (object) should have one and only one responsibility (and this responsibility should be fully encapsulated)”.

or

“A class should have only one reason to change”.

To simplify it even more, we can say that a class should do only one thing.

But how to define responsibility of a class? How to define this “reason to change”? Answer to this question is crucial and not so easy.

Consider the following sentence: “There should be no more than one reason to modify (rewrite) a class” (modifying class code in a file, not object memory state). We will try to determine this reason in this article.

Example: Suppose that we want to create an user. The first thing we need to do is to validate data. Let’s make it in service object. Such a class can see similar to this:

But…

You probably heard about Domain Driven Development (DDD). This concept is related to other terms such as information expert or rich domain model (as opposite for anemic domain models)

Let’s stop at rich domain models. This concept assumes that we keep all behaviour strictly connected to particular model in that model. So we keep data & logic that operates on it in the same place. As we are talking about OOP it seems to be obvious.

Please look on the following example.

Summary

As you have probably noticed, understanding this principle is not so simple. Mainly because defining “reason for change” can cause difficulties and there is also room for own opinions and interpretations. Implementation itself is not so difficult.

So my advice is as follows (and this applies to all rules): do not try to fulfil X rule. Strive to obtain benefits that should result from its use. That’s why we use it. Am I right?

Finally, applying this principle correctly should lead to keep our code clean, easier to maintain and thus easier to understand and analyse. Writing tests for such code is also easier. Such tests are cleaner and more maintainable too.