A deep look at the principle of single responsibility

Single responsibility principle, SRP is the first of S.O.L.I.D's five design principles advocated by Uncle Bob. Among them, the responsibility (responsibility) is expressed as "the cause of Change" (reason); the SRP is expressed as "the reason that a class should have and only one change." But if the light is literally understood, the SRP can easily be misunderstood by people words too literally. This article hopes to clarify the nature of the SRP, to avoid misunderstanding and guide the design purposes.

Motivation

The understanding of design principles should begin with its motives, that is, what are the benefits of following this principle? For the SRP, if you follow the reason that a class should have and have only one change, then "any change will only affect one class" is the fruit. It can be seen that the main motivation of SRP is the maintainability of the system, which reduces the cost of adapting to change.

Multifunction and single Change

For a single functional class, it is easier to follow the SRP, such as a tool class that converts a string to a datetime type. The difficulty in understanding SRP is in the case of a multifunctional class, which is not easy to understand the contradiction between versatility and single change. Let's take a look at a modem class example, modem has 4 functions: dial-up, hang up, send data, receive data:

class　Modem　{
　　　　 public　void　Dial(string　aPno)　{…}
　　　　 public　void　Hangup()　{…}
　　　　 public　void　Send(char　aData)　{…}
　　　　 public　char　Receive()　{…}
}

Let's examine the changes in the modem class and divide it into two categories: 1. The internal details of modem class change, such as Dial, Hangup, Send, receive and so on specific realization has changed; 2. The change of the whole of modem class, such as modem class need to add PowerOn and Poweroff method. The modem class above has multiple variation points that do not conform to the SRP.

Abstraction and abstraction levels

However, it should be noted that the above modem class is in fact a very realistic concept model, the modem itself should have these several functional points. Should the modem class be forced apart, should all classes have only one method? What causes the modem class design which conforms to the realistic conceptual model to be incompatible with the SRP? The problem lies in the abstraction and abstraction level, the modem class is the abstract of the realistic conceptual model is not wrong, but the modem class lacks the abstraction level, the low-level concept is mixed with the high-level concept, this is the problem. The following is the reconstructed modem class:

interface　IDialable{
　　　　 void　Dial(string　aPno);
}
class　Dialer　:　IDialable{
　　　　 public　void　Dial(string　aPno){…}
}

class　Modem{
　　　　 public　void　Dial(string　aPno)　{　m_dialer.Dial(aPno);　}
　　　　 private　IDialable　m_dialer;

　　　　 …　//hangup,　send,　receive类似
}

The above design abstracts each function point into a single interface, encapsulates the change behind a stable interface, and then establishes the connection of the whole modem class to the local function point by the combination. This prevents low-level changes from being transmitted to the top.

Summarize

Visible, the key to understanding the SRP is to understand the abstract hierarchy of classes, high-level class is the abstraction of high-level concepts, low-level classes are the abstraction of low-level concepts. The low-level changes only affect the lower classes, and the changes in the top level only affect the upper classes. There must be a good level of abstraction for compliance with the SRP design, so it may be helpful to design a good class by using the SRP as a guide and test. Finally, I use a few keywords to comb the context of the SRP:

Class has only one reason for change >> a change affects only one class >> change only its corresponding level