Single responsibility principle

paraphrase

At first glance, this principle , It is easy to misunderstand it as ： Functions or classes should only maintain one capability . This is certainly an important design principle , But it's not Principle of single responsibility What you want to express . The initial description of this principle is ： Any software module should have only one reason to be modified .
It may be a little difficult to understand , For software , Modification is endless . If only one reason can modify it , This reason should be avoided at the beginning of design , Be perfect . therefore , The reason here does not mean the intention of a change . But to , The objects served by this module , Is the reason for modifying the module . A further explanation is ： Any software module should only be responsible for a certain kind of actors . This is also the meaning of responsibility in the name of the principle . there Actors It is the object served by this module , It can be a user or another module .

If a module or class needs to serve multiple actors , Then with the software iteration , Changes in actors' needs , The code of the module will expand infinitely , Code coupling will be greatly improved . In this regard, it is difficult for us to guarantee the modification of a certain actor , Can not affect the behavior of other actors . The end result is , Change a question , Leads to countless other questions , The project may lose maintenance .

The wrong case

The following is an example of non-compliance with the principle of single responsibility . This module is used to control a spacecraft .

class SpaceStation {
    
public:
    //  Constructors 
    SpaceStation();
    
    void runSensor();
    void useSupplies(string type, size_t quantity);
    void reportSupplies();
    void loadFuel(size_t quantity);
    void reportFuel();
    void activeThrusters();
};

When learning the database paradigm , You will encounter a picture that violates the paradigm Supertable . This kind of table puts all the fields together , Try to put all the data in one table , However, this will bring too much redundancy to the database , Insertion exception , Modify exceptions, etc . alike , This class is also a Super class , Designers try to use a class to solve problems about SpaceStation All the needs of .
According to the principle of single responsibility , We can extract at least four actors from the current implementation of this class ：sensors; supplies; fuel; thrusters. Different actors will have different needs , Scientists will want to manage sensors, The ground command center hopes to manage well supplies, Engineers will want to manage fuel, Astronauts hope to manage thrusters.
From this, we can probably see the problem , Every actor wants to change SpaceStation, If you don't stop it ,SpaceStation It's going to get bigger and bigger , More and more complex , This is the modified “ reason ” That's too much , Consequences of violating the principle of single responsibility . indeed , In the initial stage , In this way, we can complete the task quickly , But subsequent maintenance will double the time saved at the beginning .
The solution is to separate the parts of the class responsible for different actors , Serve their respective actors , Only in this way can the problems mentioned above be avoided at the root .

Brief modification

class Sensor {
    
public:
    void runSensor();
}

class Supplies {
    
public:
    void useSupplies(string type, size_t quantity);
    void reportSupplies();
}

class Fuel {
    
public:
    void loadFuel(size_t quantity);
    void reportFuel();
}

class Thrusters {
    
public:
    void activeThrusters();
}

class SpaceStation {
    
public:
    SpaceStation();
    
private:
    Sensor sensor_control_;
    Supplies supplies_control_;
    Fuel fuel_control_;
    Thrusters thruster_control_;
};

Now that four actors have been summarized , So the SpaceStation Bring out the corresponding functions in , Put it where it should be , That is, the four classes shown in the code . This is not just a function encapsulation , More importantly, it maintains the single responsibility of the class , Each class has its own service object . The needs of service objects can be changed endlessly , But anyway , These changes will be controlled in one class , Will not have any impact on the outside . about SpaceStation for , It doesn't need to care Sensor or Fuel How is it implemented internally , What it needs to focus on is the capabilities provided by these classes , Just ask for it on demand .
Of course , The only drawback may be that it looks a little complicated , It takes more management energy , But with the continuous development of the project , These drawbacks will be wiped out .
Such changes are not the final version , For example, we can abstract a Report Interface ,Supplies and Fuel All inherit this interface to realize the corresponding reporting requirements . But for the explanation of the principle of completing single responsibility , The current revision is enough , We have successfully divided responsibilities , Drop it into the corresponding class .

summary

The principle of single responsibility is SOLID The first major principle of the principle , Following this principle at all times can divide clear boundaries for each module , This can prevent the risk diffusion caused by modifying the code . And can realize information hiding , Hide unnecessary data inside , It is convenient for subsequent replacement and permission protection . what's more , A single responsibility can ensure that the module will not be destroyed by various modifications , Help maintain code maintainability .