directory

background

An overview of the

Design principles

23 design patterns & classification

Division by purpose

According to the scope of action

conclusion

background

Design pattern is a topic that no program can avoid, and it always comes up in the interview of major factories. It was often used in my previous work, such as handwriting database connection and data source acquisition; There are tools that encapsulate Redis and things like that and we tend to use the factory model. Tell you a little story, cloud services, before we are doing a lot of open source API and SDK out, at the time of verification code, we mentioned do you want to use some design patterns, write the code on the tall some, we consider the user level may vary, just didn’t use any skills, with any level of programmers, Even if you are just graduated college students can understand the mentality, with the simplest way to achieve, the result in our comment section, by a lot of users ridicule. And then we wrote it all over again, and we abstracted it and encapsulated it, and we added some design patterns and some tricks, and then nobody made fun of it. Some framework source CODE I also browse a lot, design patterns everywhere, most of the use is just right. There are also some very convoluted, time-consuming and difficult to understand. The pursuit of simple, easy to understand can not change, good design ideas, skills to use, if not, write too simple, is not the essence of programming. So I encourage you to use these design ideas, but don’t use them for the sake of using them, and don’t show off.

An overview of the

Design Pattern is a series of routines to solve specific problems. It is not a syntax specification, but a set of solutions to improve code reusability, maintainability, readability, robustness, and security. The term “design pattern” was not originally used in software design, but in architectural design. But let’s start with the Gang of Four. In 1995, GoF (The Gang of Four) published design Patterns: The Foundations of Reusable Object-oriented Software, a collection of 23 design patterns, which set a milestone in the field of software design patterns known as GoF Design Patterns.

The essence of these 23 design patterns is the practical application of object-oriented design principles, and the full understanding of the encapsulation, inheritance and polymorphism of classes, as well as the association and combination of classes.

Design principles

  • Learning design patterns, first of all to understand the design principles, there are six principles, there are seven principles. I’m going to go through six principles, and the seventh principle runs through the process of landing the code. All in order to achieve high cohesion, low coupling.
  • Six principles: open and close principle, Richter’s substitution principle, dependence inversion principle, single responsibility principle, interface isolation principle, Demeter’s rule, composite reuse principle; The course of study calls open close principle general principle, synthetic reuse principle is the seventh principle that people say. My personal experience is that you can combine without inheritance. Each of the following principles can be summarised in one sentence.
  • On/Off principle: For extension development, close for modification. Open and closed principle is the goal, the other principles are the means of implementation, so open and closed is the general outline
  • Richter’s substitution rule: a subclass can extend the functionality of its parent class, but cannot change the functionality of its parent class. In other words, when a subclass inherits from a parent class, try not to override the methods of the parent class, except to add new methods to accomplish new functions. The purpose of this definition is to address unexpected errors that overloading/overwriting parent methods can cause in the system.
  • Dependency inversion principle: high-level modules should not depend on low-level modules, both should depend on their abstractions; Abstractions should not depend on details, details should depend on abstractions. The core idea is: program to the interface, not to the implementation.
  • The single responsibility principle: States that a class should have one and only one cause of its change, or the class should be split. That is, a class or interface does only one thing. The emphasis is on constraint classes.
  • Interface isolation principle: The programmer is required to try to break up a bloated interface into smaller and more specific interfaces, so that the interface contains only methods of interest to the customer. The endpoint is the interface. The dependency of one class on another should be based on the smallest interface.
  • Demeter’s Rule: Also known as the Least Knowledge Rule, only talk to your immediate friends, not “strangers.” The implication is that if two software entities do not communicate directly, then direct calls to each other should not occur and can be forwarded by a third party. Its purpose is to reduce the degree of coupling between classes and improve the relative independence of modules.
  • Composite reuse principle: also known as combination/polymerization reuse principle. It requires that in software reuse, we should first use association relation such as combination or aggregation, and then consider using inheritance relation. If inheritance follows the Richter substitution principle.

23 design patterns & classification

There are two popular classifications:

  • According to the purpose of the pattern; This way can be divided intoCreation pattern,Structural modeandBehavioral patternThree kinds of
  • According to the scope of the role of the model; This mode can be divided into class mode and object mode.

Division by purpose

  • The creation pattern describes how objects are created. Its main feature is the separation of object creation and use. GoF provides five creation patterns: singleton, prototype, factory method, Abstract factory, and Builder.
  • Structural patterns: Used to describe how classes or objects are arranged into a larger structure. GoF provides seven structural patterns: proxy, adapter, bridge, decoration, facade, share, and composition.
  • Behavioral patterns: Describe how classes or objects work together to accomplish tasks that a single object could not accomplish alone, and how responsibilities are assigned. GoF provides 11 behavioral models of template methods, policies, commands, responsibility chains, states, observers, mediators, iterators, visitors, memos, interpreters, and so on

According to the scope of action

  • 1. Class pattern: Used to deal with relationships between classes and subclasses, which are established by inheritance and are static, determined at compile time. Factory methods, (class) adapters, template methods, and interpreters in GOF belong to this pattern.
  • Object pattern: Used to deal with relationships between objects, which can be implemented through composition or aggregation, that can change at run time and be more dynamic. All but four of the above are object modes in GOF.
Scope, purpose Creation pattern Structural mode Behavioral pattern
Class model The factory method (Class) adapter Template methods, interpreters
Object pattern Singleton, prototype, abstract factory, builder Proxy, (object) adapter, bridge, decoration, appearance, share element, composition Policy, command, chain of responsibility, status, observer, mediator, iterator, visitor, memo

conclusion

  • By summarizing these knowledge points, I have a new understanding of the code, in the process of writing code in the appropriate scene must be used, and to use boldly, do not be afraid of trouble and difficult to understand;
  • Write code that way, and maybe that’s what the code is;
  • I’m going to go back to this when I write code later, to form norms and habits, and try to avoid arbitrary writing.