Preface: Why study design patterns

When we write code, it’s not enough to just implement functionality. This is just the beginning. I think we must be at least from the following several aspects to consider, the code of the flexibility, scalability, robustness, maintainability and readability, so as to write high quality code, and design patterns can greatly help to complete these things, look at the good open source code, can be seen everywhere in the application of design patterns in the code, We only in peacetime in the process of continuous thinking using grinding in order to accumulate at the key time

Seven principles of design patterns

First, open and close principle

Closed for modifications, open for extensions, any modifications may introduce bugs, so should be closed for modifications, extensions are easier and more flexible than modifications

2. Richter’s substitution principle

When the inheritance relationship is abstracted, any place that can be replaced by a parent class can be replaced by a child class. That is to say, when a child class inherits a parent class, it only extends the functions of the parent class and does not modify the functions of the parent class

Principle of single responsibility

The more responsibilities a class has, the less likely it is to be reused. There should be only one reason for a class to change

4. Demeter’s Rule (least Know Principle)

The less a class knows about the classes it depends on, the better. Try to encapsulate logic within a dependent class, no matter how complex it is

5. Interface isolation principle

Ensure interface purity, for example InterfaceI has method1, method2, method3, method4, method5. If ClassA just needs method1, method2. ClassB just needs method4, method5. So if ClassA has to implement these five methods to implement InterfaceI, and ClassB has to implement these five methods to implement InterfaceI, then the methods are redundant, So InterfaceI should be split into three InterfaceA with method1, method2, InterfaceB with method4, method5, and InterfaceC with method3

Six, dependence reversal principle

For interface programming, details should depend on abstractions, and abstractions should not depend on details, because abstract things are stable and details change frequently

Principle of synthesis/polymerization reuse

We know the three characteristics of object orientation: encapsulation, inheritance, polymorphism, among which the purpose of inheritance is mainly to achieve code reuse

However, the object inheritance relationship is specified at compile time, there is no way to change the implementation of inheriting from the parent class at run time, the subclass depends on the parent class, and the parent class changes and the subclass changes.

The composite/aggregate reuse principle is to use some existing objects in a new object and make them part of the new object. New objects reuse existing functionality by delegating to these objects. Object composition/aggregation is preferred

Synthesis is an emphasis on owning relationships, reflecting the rigor of the parts and the whole relationship (goose and wing/human and body) that have the same life cycle

Aggregation is A weak ownership relationship where A can contain B but B is not part of A (geese and geese/class and students)

The address on this principle to understand better www.cnblogs.com/jing99/p/12…