Design Pattern Note 3: Design Patterns several principles

1. Single Responsibility Principle

Definition: As far as a class is concerned, there should be only one cause for his change.

If a class has too much responsibility, it is tantamount to coupling those responsibilities together. A change in responsibility may weaken or inhibit the ability of this class to perform other duties. This coupling leads to fragile designs that can be subjected to unexpected damage when the changes occur.

The real thing about software design is to discover responsibilities and separate responsibilities, and if you can think of an extra motive to change a class, then this class has a redundant responsibility.

2. Open-Close principle

Software entities can be extended, but cannot be modified.

　　When you first write your code, assume that the change does not occur. When changes occur, we create abstractions to isolate changes that may occur in the future.

In the face of demand, changes to the program are made by adding new code, rather than changing the existing code.

Rejecting immature abstractions is as important as abstraction itself.

3. Dependency reversal principle

1, high-level modules and the underlying module should be dependent on abstraction.

2, detail also relies on abstraction.

4. The principle of substitution on the Richter scale

Subclasses can replace parent types.

Only if the subclass can replace the parent class, the Software unit function is not affected, the parent class is actually reused, and the subclass can also be a new behavior on the basis of the parent class.

Because of the substitution of subtypes, modules that use the parent class type can be extended without modification.

All dependencies in a program are terminated by an abstract class or interface, which is an object-oriented design.

Design Pattern Note 3: Design Patterns several principles