Single responsibility principle, open-closed principle, dependency inversion principle

The "big talk Design Pattern" describes three principles in three consecutive chapters and extracts these important quotations for my understanding in the future.

 

Simple response Principle: For a class, there should be only one reason for his change.

When a class assumes too many responsibilities, it is equivalent to coupling these responsibilities. A change in responsibilities may weaken or suppress the class's ability to fulfill other responsibilities. This coupling will lead to a fragile design, and when the design changes, the design will suffer unexpected damages.

What software design really needs to do is to discover responsibilities and separate them from each other.

Method for Determining whether a single responsibility is used: If you think of more than one motive to change a class, this class has more than one responsibility, and you should separate the duties of the class.

 

Open-closed principle: software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified.

That is, the extension is open for extension and the change is closed for modification ).

A good practice is to take action immediately when a change occurs. In our initial compilationCodeIf the change does not occur. When a change occursCreate abstraction to isolate similar changes.

 

Dependency inversion principle: Abstraction should not depend on details, and details should depend on abstraction.

• High-level modules should not depend on low-level modules. Both of them should depend on abstraction.
• Abstraction should not depend on details. Details should depend on abstraction.

The high-level module should not depend on the underlying module ==the high-level should not rely on calling the lower-level module. My understanding is that the high-level module depends on the lower-level interface, so that the High-level class can be reused.

 

Lee's replacement principle: the child category must be able to replace his parent category.

That is, replace the parent class with its subclass,ProgramThe behavior is not changed.

Only when the child class can replace the parent class and the functions of the software unit are not affected can the parent class be reused. The Child class can also add new behaviors based on the parent class.

All dependencies of a program are terminated by abstract classes or interfaces, that is, object-oriented design, and vice versa.