Single Responsibility Principle for Object-Oriented Design Principles (SRP)

Single Responsibility Principle for Object-Oriented Design Principles (SRP)

 

This principle was once described in the books of Tom DeMaro and Meilir Page-Jones and called it cohesion ). They define cohesion as functional correlations between components of a module.

Single Responsibility Principle (SRP)

Single Responsibility Principle (SRP): For a class, there should be only one reason for its change.

The principle of single responsibility tells us that in a software system, if a class assumes too many responsibilities, these responsibilities are coupled together, the change in one role is more likely to weaken and suppress the ability of this class to fulfill other duties. This coupling will lead to a fragile design. When a change occurs, the design will be unexpectedly damaged [ASD], in fact, when programming, we naturally add a variety of functions to a class.
The single responsibility principle is the guiding principle for achieving high cohesion and low coupling. It is the simplest but most difficult to use. We will naturally combine our responsibilities. Much of what software design really needs to do is to discover responsibilities and separate those responsibilities from each other, the designer needs to discover and separate different responsibilities of the class, and the multiple responsibilities of the Discovery class require the designer to have strong analysis and design capabilities and relevant practical experience.

What is duty

In SRP, we define responsibility as a reason for cheange ). If you can think of more than one motive to change a class, this class has more than one responsibility. Sometimes it is hard for us to notice this. We are used to taking responsibilities into account in groups.

View the following class library. This is an online image processing class used to crop images and generate thumbnails. This class has many responsibilities and is used to open different types of images (jpeg, png, gif ...), Computation Based on Different Cropping and compression methods, compress and crop images, and save images of different types. This class assumes many responsibilities. If this class is currently used for graph cutting tools for the GD library, the entire class will be changed in the future because GraphicsMagick will be used to process images for various reasons, I believe many people simply change to another class for processing.

Example 1
In this example, we separate the duties of the Images class, retain the external services of Images, separate image processing, and add an image processing interface of ImagesHandle, currently, the system supports jpg and png Image Processing. Therefore, javashandle and PngHandle implement the ImagesHandle interface. In Images, different ImagesHandle instances are called Based on the image type. The crop and thumb methods are calculated based on different processing methods, and then the crop of the ImagesHandle instance is called to crop the image, the save method is saved based on different ImagesHandle instances. The specific class diagram is as follows:

Example 2
In the example of improvement, Images, as a unified service interface, may feel that this class graph is no longer a problem, but Images is also responsible for cutting graph operations and coordinating ImagesHandle instances, therefore, the separation of duties is not perfect. This is just an example. It has not been implemented yet. In implementation, we will also find that the type conversion between ImagesHandle fails to be implemented. In fact, it is very easy to improve these problems, use a class to implement the image cutting algorithm. Change save () of ImagesHandle to save (ImagesHandle Handle, File = null.
　　

Why keep SRP?Reduces coupling between classes.
If the coupling between classes is reduced, only one class is modified when the demand changes, thus isolating the changes. If a class has multiple different responsibilities, they are coupled together, when a responsibility changes, other responsibilities may be affected. Improve the reusability of Classes
Repairing a computer is much easier than repairing a TV. The main reason is that the coupling between various components of the TV is too high, while the computer is different. The memory, hard disk, sound card, Nic, and keyboard lamp parts of the computer can be easily detached and assembled separately. A part is broken. Just change it to a new one. Improve readability, improve readability, reduce the complexity of the class, and clearly define what responsibilities are implemented.

Reduces the risks caused by changes and is helpful for system scalability and maintainability.

There is a problem with the use of a single responsibility principle. There is no clear division standard for "responsibilities". Too detailed division of duties will lead to a sharp increase in interfaces and implementation classes, but will increase the complexity, reduces the maintainability of the Code. Therefore, we need to analyze the specific situation when using this responsibility. The suggestion is that the interface must adopt the single responsibility principle to implement the single responsibility principle in class design as much as possible. It is best to cause a class change for one reason.
　　The single responsibility principle is not only reflected in the class design, but should follow the single responsibility principle for class methods, functions, class library packages, modules, components, etc, only one change can cause encapsulation code changes.