The real state of design patterns is to understand and then forget.
Single responsibility principle
Do only one thing.
The smaller the granularity, the better the reuse and the less repetitive code, but the larger the amount of code, you need to weigh it yourself.
Richter's Substitution Principle
Subclasses can extend the functions of the parent class, but cannot change the original functions of the parent class.
Can minimize the repetitive action of the class, but also to prevent calling the same name method of the parent and child classes to cause different effects.
Problem: There are too many levels of inheritance, and the subclasses will be huge. If the methods of the parent class are not needed, it will be redundant.
example:
The father will move and use the legs. The son can also move and use the car.
The caller wants to walk with his legs, but if he calls his son's movement, there will be a problem.
Therefore, the son needs to implement the driving method and let the caller choose.
Principle of opening and closing
Write new code without changing the old code.
Use abstract classes to allow different people to achieve different effects and achieve extensions.
example:
Abstract class mobile
Class A implements legs for mobile
extension
Class B implements bicycles for mobile The
caller is free to choose A or B
Dependence inversion principle
To interface-oriented programming, not implementation-oriented programming.
Use interface classes to allow different people to achieve different, but the effect is the same.
The caller is calling the interface and does not need to care about the implementation, the effect is the same.
example:
Interface shopping method
Class A realizes shopping method on Taobao
Class B realizes shopping method on Jingdong
Shopping class initialization injection shopping method class
The caller chooses different shopping methods to inject, and then uses the shopping class
Interface isolation principle
Reduce interface dependence and
provide more in line with requirements and more specific interfaces. That is, encapsulate in combination with business.
example:
Set meal.
Users can order steak, bread, noodles, broccoli, and corn.
But all of these are put into one interface class, which is a lot.
Can provide staple food, meat, soup.
Or children's package, double package, family package.
It is mainly to classify and integrate small interfaces based on the scene.
Dimit's Law
Avoid direct calls or direct communication.
Also called hierarchical dependence.
From the perspective of the dependant, only depend on the objects that should be depended on.
From the perspective of the dependant, only expose the methods that should be exposed.
example:
Mobile phone app content class The
content class only depends on the APP, not the mobile phone.
There is another kind of understanding that increases the burden on the caller.
It is also called increasing the API surface area, which is to make the caller less concerned about the implementation logic .
example:
An error handling method has several types of errors.
The first way of writing is to provide a class, and then you judge based on the type of error in the class. So once the type is changed, the caller's code must be changed.
The second way of writing is to provide a verification method. You only need to call this method to know if it is an error or what it is.
Synthetic reuse principle
Less use of inheritance, more use of combination
is to divide the code into block A, block B, C...
and then make building block 1 contains the following A and B, and building block 2 may be BCD. Free combination, more flexible.
to sum up
Go language is still great.
There is no inheritance, only structures and packages. Isn't this just one piece?
There are no pure virtual classes, only interfaces, which is directly interface-oriented programming.
After reading it, forget these rules. Just remember how to do it. What is right and what is wrong. We just don’t remember what principles correspond to what, but only remember how it should be and why.
About object orientation
We must pay attention to two aspects: bottom thinking and abstract thinking
(1) Low-level thinking: go down, grasp the bottom of the machine, and understand the structure of the object from the micro level
- Language structure
- Compile conversion
- Memory model
- Runtime mechanism
(2) Abstract thinking: Upward, how to abstract the world around us into program code
- Object-oriented
- Component packaging
- Design Patterns
- Architecture pattern
Encapsulation: hide internal implementation
Inheritance: reuse existing code
Polymorphism: rewrite object behavior