Design patterns are the experience summed up by predecessors. They solve different problems in different scenarios. Therefore, they should not be copied "simple", nor should they be patterns for the sake of patterns, but should be applied flexibly.
I have read a lot of articles on design patterns on the Internet, and there are also many books. I couldn’t understand it at first, but after learning object-oriented, I found that those examples (cats, dogs) can be understood. However, in I don't know how to use it in a specific project.
All codes vary from project to project, and those routines of design patterns may not be suitable for you. The reason why I can't understand it is because there are too many concepts to remember, and the amount of code is not enough. We often talk about "quantitative change" -> "qualitative change", without a certain amount of code, it is impossible to understand those design patterns.
Go beyond the limits of the concept
Let's look at a piece of code:
In the TEntity class, there is no CreationTime field, but its parent class IHasCreationTime has it. What I didn't understand at the time was why it was converted to the parent class and changed the value of the attribute CreationTime, so the value of the model instance also changed?
The design pattern talks about the "Richter Replacement Principle". It talks about a lot of concepts of penguins and birds, but it doesn't talk about the essence. You find that you know the relationship between penguins and birds in the book. As a result, the code understanding is still relatively blurry.
Here is the application of polymorphism. Most of the traditional 23 design patterns are implemented with the characteristics of object-oriented "polymorphism". If you don't understand polymorphism, don't learn design patterns, and you won't experience the benefits.
In the above code, why does the subclass switch to the parent class, change the value of the "parent class", and the subclass also changes?
Reason: The conversion from subclass to superclass, no matter how the subclass is transferred, its instance remains unchanged, and the transfer to the superclass just decides what form (the superclass) to use to access it. And his actual memory storage address is unchanged.
Polymorphism: The parent class can point to the child class, the parent class can accept the child class, it's that simple.
Object-oriented three characteristics: encapsulation, inheritance, polymorphism.
Object-oriented five principles: single responsibility, open-closed principle, dependency inversion principle, Liskov substitution principle, interface isolation principle.
Principles of use: Use combination first, and inheritance less (too many children will be pitiful).
Use design patterns to achieve the best results: high cohesion (within modules), low coupling (between modules)
The best design pattern is to forget about the design pattern, don’t be limited by the concept of rules and regulations, and write good code at will. The premise is to learn the internal skills, lay a good foundation, write and practice more, accumulate code, and change from quantity to quality.