Principle of sole responsibility

The term SRP was coined by Robert S. Martin in a self-titled article as part of SOLID , which became popular thanks to his book, Rapid Software Development. Principles, examples, practice. ” ^[1] . Martin described SRP based on a pattern described by Tom DeMarco ^[2] and Maylir Page-Jones ^[3] called connectivity .

In SOLID , the letter “S” is an abbreviation formed by the abbreviation of the English name for the principle of sole responsibility.

Martin defines responsibility as the reason for the change and concludes that classes should have one and only one reason for change. For example, imagine a class that compiles and prints a report. Such a class can change for two reasons:

1. report contents may change
2. report format may change.

It is logical that both aspects of these causes are actually two different responsibilities. SRP says that in this case, you need to divide the class into two new classes, which will be characterized by only one responsibility. The reason why you need to keep your classes focused on their only goal is because it makes classes healthier. As for the class given above, if there was a change in the process of compiling the report, there is a high probability that the code responsible for printing will become unusable.

When developing different behaviors of one class, a “ Divine object ” often appears, which in OOP is considered antipattern . Compliance with the principle of sole responsibility avoids this antipattern.

The question is, when is it worth using this principle? Nevertheless, the principle is not the law and SRP should be applied depending on how the application changes:

• if, when changing the code responsible for one responsibility, corrections of the code responsible for another responsibility appear in the application, then this is the first SRP violation signal.
• if changes to the code responsible for one responsibility do not make changes to the code responsible for another responsibility, then this principle can not be applied.

Blindly following the principle of sole responsibility leads to excessive complexity of the application, its support and testing. SRP should be used only when justified. The SRP principle can only be applied when:

• the class object becomes too much permissible;
• domain logic is concentrated in only one class;
• any change in the logic of the object’s behavior leads to changes in other places of the application, where this was not originally intended;
• you have to test, fix errors, compile various places in the application, even if a third party is responsible for their performance;
• it is impossible to easily separate and apply the class in another area of ​​the application , as this will pull unnecessary dependencies.

Sharing responsibilities is a common practice and there is nothing wrong with that as long as it is easy to maintain. Following the principle of sole responsibility depends on the functions of the software product and is the most difficult when designing applications.

ActiveRecord , a pattern that makes it easy to link object data and data from a database, is often cited as an example of SRP violations. In ActiveRecord, many responsibilities are concentrated in one place and therefore it can be argued that ActiveRecord violates SRP and thus becomes antipattern. ^[4] In some cases, this statement is controversial, since an object that implements ActiveRecord, does not contain any business logic, but provides a table from a database, has only one reason for change (table change), which does not contradict the definition of the SRP principle ^[5] .

The following methods allow you to observe the principle of sole responsibility:

• Development through testing
• Class Selection Template
• Facade template
• Proxy Template
• DAO

A classic example ^[6] of SRP violation is a situation where a business rule system ( BRMS ) needs to deal with persistent storage ( ). At the first stages of designing such systems, a class is created that processes the business rules and contains the logic for working with the database. With an SRP violation, signs of a poor design appear, such as:

• the system is difficult to change, since any minimal change causes a snowball effect affecting other components of the system.
• as a result of ongoing changes, the system is destroyed in those places that are not directly related to the directly modifiable component.

If the system was initially developed through testing ( TDD ), then this problem might not have arisen. Based on tests, developers can quickly imagine what functionality the user needs. Thus, the details of the class appear long before the final implementation of the solution, thereby influencing the design of the developed system. But it also happens that development through testing does not lead to the application of the “ Class Selection ” template, then refactoring is applied to the system using the “ Facade ”, DAO or “ Proxy ” templates.

SRP suggests dividing universal classes into concrete ones, which will make them simple and easy to maintain. A similar idea is also put forward by the KISS principle . ^[7]

• GRASP
• Separation of Concerns
• Cohesion
• Chain of responsibility
• Persistence
• RDD

• Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. - Pearson Education, 2008 .-- ISBN 978-0-13-608325-2 .

• The principlesles of ood