Big talk design pattern C + + implementation-Chapter 3.4.5.11-Design Law

I. Single principle of responsibility

(1) In the case of a class, there should be only one cause for it to change.

(2) If a class takes on too much responsibility, it is tantamount to coupling these responsibilities together, and a change in a duty may weaken or inhibit the ability of the class to perform other duties. This coupling leads to a fragile design that, when changed, is subjected to unexpected damage.

(3) Much of what the software is designed to do is to discover responsibilities and separate those responsibilities from each other.

Ii. the principle of open closure

(1) Software entities (classes, modules, functions, etc.) should be extensible, but not modifiable.

(2) in the face of demand, changes to the program are made by adding new code, rather than changing the existing code.

(3) We hope to know the changes that may occur soon after the development process is launched. The longer the lock waits, the more difficult it is to create the correct abstraction.

(4) The open-closed principle is the core of object-oriented design. Following this principle leads to the huge benefits claimed by object-oriented technology, which is maintainable, extensible, reusable, and flexible.

(5) Developers should abstract only those parts of the program that exhibit frequent changes, but it is also not a good idea to abstract every part of the application. Rejecting immature abstractions is as important as abstraction itself.

Iii. reliance on the reversal principle

(1) High-rise modules should not rely on low-level modules. Two should all rely on abstraction.

(2) Abstraction should not depend on details. Detail should be dependent on abstraction.

(3) Dependency reversal Law is the core of object-oriented design.

Iv. principle of substitution on the Richter scale

(1) A subtype should be able to replace its parent type.

(2) It is because of the substitution of subtypes that a module using the parent class type can be extended without modification.

V. The law of Dimitri

(1) If two classes do not have to communicate directly with each other, then these two classes should not have a direct interaction. If one of the classes needs to invoke a method of another class, the call can be forwarded through a third party.

(2) The fundamental idea of Dimitri law is to emphasize the loose coupling between classes.

(3) The weaker the coupling between the classes, the more beneficial the reuse, and a weakly coupled class is modified without affecting the related classes.

Big talk design pattern C + + implementation-Chapter 3.4.5.11-Design Law