Six design principles in the Zen of design patterns

1. Single Responsibility Principle (SRP)

Original Definition: There shoshould never be more than one reason for a class to change.

BOTH: there should be and only one reason for class changes.

Benefits of a single responsibility:

1. The complexity of classes is reduced, and all responsibilities are clearly defined;

2. improved readability, reduced complexity, and improved readability;

3. Enhanced maintainability and readability, of course, improved readability;

4. changes are essential to reduce risks caused by changes. If a single responsibility for an interface is well performed, modifications to an interface only affect the corresponding implementation class, it has no impact on other interfaces, which is of great help to system scalability and maintainability.

Ii. liskov substitution principle LSP)

Definition 1: if for each object O1 of type s there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged where O1 is subsitituted for O2 then S is a subtype of T (if the corresponding type is s Object O1, oh there is a t object O2, enable all defined by TProgramWhen P replaces all objects O1 with O2, the behavior of program P does not change, so type S is the child type of type T)

Definition 2: functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it (all references to the base class must transparently use its subclass objects)

Generally speaking, as long as the Child class can appear in any place where the parent class can appear, and replacement with the Child class will not produce any exceptions or errors, the user does not need to know whether it is a parent class or a child class. However, in turn, it will not be feasible. Where the child class appears, the parent class may not be able to adapt.

Layer-4 Meanings of the Lee's replacement principle:

1. Subclass must fully implement the parent class method;

2. Subclass can have its own features;

3. When overwriting or implementing the parent class method, the input parameters can be enlarged;

4. output results can be reduced when overwriting or implementing the parent class method;

Iii. Dependency inversion principle (dependence inversion principle DIP)

Original Definition: high level modules not depend upon Low Level modules. Both shoshould depend upon quota actions. Quota actions shocould not depend upon details. Details shold depend upon abstactions.

BOTH:

1. The high-level module should not depend on the underlying module, and both should depend on its abstraction;

2. abstraction should not depend on details;

3. Details should depend on abstraction;

This principle is manifested in Java:

1. dependencies between modules occur through abstraction, so that no direct dependency is established between classes. dependencies are generated through interfaces or abstract classes;

2. The interface or abstract class does not depend on the Implementation class;

3. Implement class dependent interfaces or abstract classes;

The more streamlined definition is "interface-Oriented Programming" ---- OOD (object-oriented design, object-oriented design)

The nature of the dependency inversion principle is to make the implementation of each class or module independent from each other through abstraction (abstract class or interface) without affecting each other, so as to implement the loose coupling seen by the module. If you need to use this rule, follow the following rules:

1. Every class has an interface or abstract class, or an abstract class and an interface as much as possible (this is the basic requirement of this principle. Both interfaces and abstract classes are abstract, with abstraction, dependency inversion may be possible );

2. The surface type of the variable should be an interface or abstract class;

3. No class should be derived from a specific class;

4. Try not to override the method of the base class (if the base class is an abstract class and the method has been implemented, try not to override the subclass. Inter-class dependency is abstract, overwriting abstract methods will have a certain impact on the stability of Dependencies );

5. It should be used in combination with the Lee's replacement method;

Iv. Interface isolation principles

Meaning of the interface isolation principle:

1. The interface should be as small as possible (core definition );

2. Interfaces must be highly cohesive;

High Cohesion improves the capability of interfaces, classes, and modules and reduces external interactions.

3. Custom Services;

Customized services provide excellent services for each individual.

4. Limited interface design;

5. Law of Demeter (dump) is also known as the least knowledge principle LKP)

Definition: an object should have a minimum understanding of other objects.

In layman's terms, a class should know less about the classes that need to be coupled or called, and the better.

Vi. Open and Close principles

Definition: software entities like classes, modules and functions shocould be open for extension but closed for modifications

Both: A software entity such as a class, modules and functions should be open to amplification, and changes should be closed. (Software entities should be changed through extensions (integrated classes, implementing interfaces), rather than modifying existingCode)