SRP: The Single Responsibility Principle

Introduction

This is the 8th article in the System Design and Software Architecture series. In this article, we are discussing the sub-topic of the design principle, SRP: The Single Responsibility Principle.

What is The Single Responsibility Principle

The Single Responsibility Principle is a core software engineering principle that determines how we should modulate the code in object-oriented programming.

The argument for the Single Responsibility Principle is relatively simple: it simplifies the execution of your software and prevents unexpected side effects of future changes.

Requirements change during the software development process. Each requirement changes at least one class. The more responsibilities you have in your class, the more you want to change them.

As soon as one responsibility in your class changes, you will change it. If it has only one responsibility, it is more likely that you will obviously have to change it.

The principle of single responsibility is closely related to the concepts of coupling and cohesion. Coupling refers to how different aspects of an application are linked together and how closely the contents of a class or package are connected. Since a class is a single unit that should be used or not used at all (excluding static methods and data), all the contents of a single class are tightly bound. When other classes use a class and that class changes, the dependent classes need to be checked to ensure they are working correctly with the new behavior of the class. If there is poor cohesion in a class, some parts may change and only certain classes may use them while others remain the same.

However, all dependent classes in the class need to be re-examined as a result of the change, increasing the total surface area of the application affected by the change. Instead, if the class is divided into several higher-cohesion classes, each of them will use fewer of the other elements of the system. So modifying any of them will have less effect on the whole system.

Benefits of the Single Responsibility Principle

The argument for the Single Responsibility Principle is relatively simple: it simplifies the execution of your software and prevents unexpected side effects of future changes.

Frequency and Effects of Changes

We all know that needs change over time. They also change the responsibility of at least one class each. The more responsibilities you have in your class, the more you want to change them. If your class executes different responsibilities, they are no longer independent of each other.

As soon as one of your class responsibilities changes, you must change it. If it has only one responsibility, it is more likely that you will obviously have to change it.

While it may not seem like a big deal, it does affect all classes or components that depend on the changed class. Depending on your change, you may need to update dependencies or change dependency classes again. They may use only one of the other responsibilities enforced by your class, but you must update them anyway.

Easier to Understand

The Single Responsibility Principle offers another significant benefit. Classes with only one responsibility, software components, and microservices are easier to explain, understand, and implement than those that provide a solution to everything. This reduces the number of errors, speeds up your development, and simplifies your life as a software developer.

However, it is important to be sure not to simplify your code too much. Some developers take the Single Responsibility Principle to the extreme by creating classes with only one task. Then, when they want to write some real code, they have to inject a lot of dependencies, making the code very unreadable and confusing.

Therefore, the Single Responsibility Principle is an important rule to make your code more understandable, but do not use it as your programming bible. Use common sense when developing code. It does not make sense to have multiple classes containing only one function.

How Can This Principle Be Misleading?

The strategy for implementing SRP in our software is to know the responsibilities of each class.

However, every developer has their own vision of the class objective, which makes things confusing. Since we do not have strict instructions on how to implement this principle, we are left with our own interpretations of what constitutes responsibility.

This means that as creators of our app, we determine if something is within the scope of the class.

When writing a class according to the SRP principle, we need to think about the problem domain, business needs, and application architecture. It is very subjective, making it difficult to implement this principle. It will not be as simple as the examples in this tutorial.

Cohesion

• Following the SRP principle, our classes will adapt to one activity. Their methods and data are concerned with one clear purpose. This means high cohesion as well as robustness combined to reduce errors.
• Cohesion is essential when designing software based on the SRP principle, as it helps to find individual responsibilities for our classes. This concept helps us find classes with more than one responsibility.
• If we do not think about cohesion and do not have a clear definition of what a class is responsible for, we may say that text writing and updating are two different and separate jobs. With this in mind, we may conclude that these should be two separate classes: WriteText and UpdateText.
• The reality is that we will get two classes that are tightly bound and loosely integrated, which should almost always be used together. All three methods can perform different operations but essentially serve one purpose: text manipulation. The main thing is not to overestimate.

LCOM is one of the tools that help to achieve a high level of cohesion in methods. Essentially, LCOM measures the relationship between class components and their relationship to each other.

Examples

Here are some examples of responsibilities that have to be separated:

• Relentless effort
• Validation
• Notification
• Error handling
• Logging
• Class selection / acceleration
• Modeling
• Analysis
• Mapping

Types of Responsibilities

Instead of defining responsibility in abstract terms, it can sometimes be wiser to list the actual types of responsibility. Here are some examples (derived from Adam Worsky’s object classification in applications, distilled in his thought-provoking post on Scala dependency injection):

Business Logic

For example, extracting a phone number from a text, converting an XML document to JSON, or classifying a money transaction as fraud. At the class level and above, business logic is responsible for knowing (or consolidating) business operations: for example, a class that knows how to convert XML documents to JSON or a fraudulent transaction detection service.

External Integration

At the very least, this can be an integration of modules within the application, such as queuing a message to be processed by another subsystem. There are also integrations with systems such as system timekeeping or testing. Finally, there are integrations with external systems such as RPC calls for database transactions, reading or writing to a distributed queue such as Kafka, or other services.

Depending on the class, module, and service level, the responsibility for external integration lies in knowing how to integrate the external partition: for example, a class that knows how to read system time (or exactly what java.time does) or a service that communicates with an external API.

Data

Data can be something like a person’s profile on a website, such as a JSON document or a message. Embedding a piece of data can be the responsibility of a class (object) but not a system, module, or service. The specific type of data configuration can be a collection of parameters for another system, class, or system.

Control Flow

Control flow refers to the activation or part of the data flow of an application. An example of this responsibility is a way of calling out components that have different responsibilities to each other.

Conclusion

Thanks for reading the article SRP: The Single Responsibility Principle as an essential component in system design and architecture.

Originally published at https://onloadcode.com on January 10, 2021.