SOLID 1 – Single-Responsiblity Principle (SRP)

Yes, friends, I have been sharing posts about C++ and have not written many posts about software engineering stuff. This will change from this post and I will try to increase the frequency of such topics. Let us, talk about the topic of this post (in fact post series now on).
So if I would summarize my post with one word, it would SOLID. It may not sound familiar, but if I say S.O.L.I.D. then you may immediately undestand that it is an acronym.

Let me share with you what S.O.L.I.D. stands for.

S – Single-responsiblity principle (SRP)
O – Open-closed principle (OCP)
L – Liskov substitution principle (LSP)
I – Interface segregation principle (ISP)
D – Dependency Inversion Principle (DIP)

Each of these has been defined as the minimum principles to be followed for Object Oriented Software Development by Robert C. Martin who is also known as Uncle Bob. You can also refer to this document for more details. Although the object-oriented programming approach can increase the reusability / flexibility compared to the structured programming approach and handle the complexity, misuse can cause the contrary. The main purpose of these principles is to eliminate such problems and to obtain more agile, reusable and maintainable software.

In this context, it is essential to me that most developers, especially those who develop object oriented software, should be familiar with these principles. So let’s take a look at each of these without wasting any more time.

Instead of explaining all these principles in a single article, I decided to explain them in separate articles. I think, it will be more understandable and easier to read. In this article, we will look at the principle of Single Responsibility.

For other SOLID principles, you can check out following links:

  1. SOLID 1 – Single-responsibility Principle
  2. SOLID 2 – Open-closed Principle
  3. SOLID 3 – “Liskov Substitution” Principle

Single-Responsiblity Principle:

Image result for single responsibility image

As its name implies, the most important purpose of this principle is: for object oriented software, each class should only have one responsibility.

This is, in fact, also closely related to the cohesion criterion, which is important for software design. This concept expresses how much the method and data of the given component relate to each other to perform the designated class functionality. The high level of cohesion makes a great contribution to achieving good software design.

Uncle Bob has also made a very famous definition of this principle: “We only have one reason to change the class” (you can take a look at this address for details). In other words, the change of the elements in the class must be for the same reason. If different reasons are required for different changes, then those should be separated. So what do we mean by reason? Let me try to give a brief example here.

For instance, let us assume that we have a class which is responsible for external communication and have following capabilities:

When we look at the class that I gave above, there are basically two functions: communication via TCP / IP socket and recording of communication history. We can think of sending each message and recording the message history as a separate capability. The possible changes that may happen, there may be a need for supporting JSON instead of XML format for recording. It may also be the case of using serial channels or UDP instead of TCP. As you can see, there are multiple reasons for this class for change! According to SRP, we expect only one of them to cause change. Let’s try to make this piece of code suitable for SRP.

First of all, let us move history recording capability to a separate class. As we design this class, let us also consider multiple formats. We can develop following classes for this purpose:

When we need to use a new message recording format, we no longer need to change the ExternalCommunication class. Similarly, we can define and use the following classes for the communication purpose.

Our final class will be as follow which also supports SRP. We have achieved a class that is quite expandable 🙂

In addition to this code example, I also want to share the example that is given by Uncle Bob. You can find class diagram related with that example below.

Violation of SRP

It can be observed that Rectangle class has at least two responsibilities. These are: drawing a rectangle by GraphicalApplication via GUI (draw() API) and calculating rectangle area by ComputationalGeometryApp (area() API). At first glance, you may not see any problem, let’s take a closer look.

The first problem we will see here is that the ComputationalGeometryApp class, which only needs a rectangular area calculation, also includes indirect dependency on the GUI. Similarly, due to a change in GUI, this change may cause another change in ComputationalGeometryApp. This, in fact, violates the rule that there must be only one reason for change.

So how can we handle these issues? Let us look the resultant class diagram that resolve these issues:

Design SRP-proof

As it can be seen, by adjusting the dependencies as shown above, the dependency between the two classes has also disappeared and our design has become compatible with SRP.

After the above examples, one might ask: So how can we really tell if our class has more than one responsibility? At this point, the concept of cohesion that I mentioned at the beginning of my writing comes to our rescue. As an example, we will take a look at the Java example given at “SRP is a Hoax” page:

Now, when we try to blindly implement SRP in this class, we probably have classes like ExistanceChecker, ContentReader and ContentWriter. To read and display data on the Aws class in a simple way, we will need to use code like the following:

As you can see, these classes will often be used together. In addition, these classes exhibit high coupling and low cohesion. Therefore, it is not right and feasible to separate these classes in this way.

When using this principle under normal circumstances, you need to assess the cohesion levels of your classes carefully.

With this question, we have completed our first principle. See you next week on principle two, take care of yourself.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.