Six principles of design pattern: single responsibility principle

There are six principles in design mode: Interface isolation

Six principles of design pattern: dependency inversion principle

Six principles of design pattern: Richter’s substitution principle

There are six principles of design patterns: Demeter’s Law

Six principles of design pattern: open and close principle

Single responsibility principle definition:

Objects should not have too many functions, just as one cannot multitask at one’s heart; for example, too much work (variety) will cause one to collapse. Only concentration can ensure high cohesion of objects; Only uniqueness can ensure fine granularity of objects.

Solve a problem:

If there are two classes A and B, when the requirements of A change need to be modified, can not cause the problem of class B.

Status:

In practice, it is difficult to follow the single responsibility principle, because as the business changes, the responsibility of the class changes, that is, responsibility diffusion. For example, class A completes the function of responsibility P, but with the later business refinement, responsibility P is decomposed into smaller P1 and P2. In this case, according to the principle of single responsibility, A needs to be divided into two categories to meet the responsibilities P1 and P2 after subdivision respectively. But in real development, if the logic of the class is simple enough, it can violate the single responsibility principle at the code level. If a class has enough methods, the single responsibility principle can be violated at the method level.

Classic case:

Use a class to describe the scene of an animal breathing

Namespace MyDemo {internal class Animal {public void breath(string Animal) {Console.WriteLine($"{Animal} breath "); }}}Copy the code
namespace MyDemo { internal class Program { private static void Main(string[] args) { Animal animal = new Animal(); Animal. Breath (" 🐂 "); Animal. Breath (" 🐖 "); Animal. Breath (" 🐎 "); Animal. Breath (" 🐟 "); }}}Copy the code

As you can see from the example, the Animal class is no longer sufficient to support the responsibilities required by the client, because 🐟 is a water draft. If you follow the single responsibility principle, you need to split the Animal class.

Internal class Terrestrial {public void breath(string animal) {console. WriteLine($"{animal} breathe air "); }} Internal class Aquatic {public void breath(string animal) {Console.WriteLine($"{animal} draft "); }}Copy the code
internal class Program { private static void Main(string[] args) { Terrestrial terrestrial = new Terrestrial(); Terrestrial. Breath (" 🐂 "); Terrestrial. Breath (" 🐖 "); Terrestrial. Breath (" 🐎 "); Aquatic aquatic = new Aquatic(); Aquatic. Breath (" 🐟 "); }}Copy the code

You will find that for simple business logic, it is too cumbersome to split each subdivision, and both the server and client code need to be changed accordingly. So making changes directly to the original class violates the single responsibility principle, but costs less.

Public void breath(string Animal) {if ("🐟".Equals(Animal)) {Console.WriteLine($"{Animal} draft ");  } else {console. WriteLine($"{animal} breathe air "); }}}Copy the code

Advantages:

1. Reduce the functional complexity of classes

2. Improve system maintainability

3. Low risk of change

Source: www.cnblogs.com/az4215/p/11…