Big talk design pattern third--some design principles

Single Duty:

As far as a class is concerned, there should be only one cause for it to change.

If a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in a duty may weaken or inhibit the ability of the 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 those responsibilities from each other. If you can think of more than one motive to change a class, then this class has a paranoid responsibility.

Open-closed principle:

Software entities (classes, modules, functions, and so on) should be extensible, but not modifiable.

When we first wrote the code, we assumed that the change would not happen. When changes occur, we create abstractions to isolate similar changes that occur later.

What we want is to know the changes that are likely to occur shortly after the development process is underway, and the longer it takes to identify possible changes, the more difficult it is to create the right abstraction.

The open-close principle is the core of object-oriented design. Following this principle can lead to significant benefits to the technology that are maintainable, extensible, reusable, and flexible. Developers should abstract only those parts of the program that are showing frequent changes, but it is also not a good idea to deliberately abstract each part of the application. Rejecting immature abstractions is as important as abstraction itself.

Dependency reversal principle:

1, high-level modules should not rely on the underlying module, two should be dependent on abstract (abstract class, interface ...) 2. Abstraction should not depend on details. Detail should be dependent on abstraction.

On the Richter substitution principle: subtypes must be able to replace their parent types. In other words, the parent class is replaced by its subclass, and the behavior of the program does not change.

　　

(Dependency reversal principle: the upper and lower layers should be dependent on abstraction.) ）

　　Because the substitution of subtypes makes it possible to extend a module that uses a parent type without modification.

　　Dependency reversal can be said to be the object-oriented design of the logo, in which language to write the program is not important, if the writing is to consider how to focus on abstract programming rather than the details of programming, that the program all the dependencies are terminated in the abstract class or interface, that is, object-oriented design, which is the process of design.

Big talk design pattern third--some design principles