in Gof's design patterns:elements of reusable object-oriented software, three classes (creation [abstraction of the instantiation process of a class], structural type [ Describes how to combine a class or object to form a larger structure], behavior [to divide responsibility between different objects and abstract the algorithm]) 23 design patterns, including: abstract Factory (Abstraction Factory mode), builder (Builders mode), Factory Method (Factory mode), Prototype (original model mode), Singleton (singleton mode), facade (façade mode), Adapter (adapter mode), Bridge (bridge mode), Composite (compositing mode), Decorator (decorative mode), Flyweight (enjoy meta mode), Proxy (Command mode), interpreter (interpreter mode), Visitor (visitor mode), Iterator (iterative sub-mode), Mediator (mediator mode), Memento (Memo mode), OBSERVER (Observer mode), State (status mode), strategy (policy mode), template method (templated methods mode), Chain of Responsibility (responsibility chain mode).
The so-called design pattern is a summary of the repeated use of code design experience (a proven solution to a problem in the context). Design patterns are used in order to reuse code, make code easier for others to understand, and ensure code reliability. Design patterns make it easier and easier to reuse successful designs and architectures. The presentation of proven technologies into design patterns will also make it easier for new system developers to understand their design ideas.
The "supplemental" design pattern is not a remote programming concept, as some places boast, but the design pattern is the practice of object-oriented programming principles, and the object-oriented programming principles include:
- Single Duty principle: A class only does what it has to do. (single duty principle wants to express is "high cohesion", write code Ultimate principle only six words "high cohesion, low coupling", just like sunflower treasure or evil sword spectrum of the central idea of eight words "to practice this work must first self-palace", so-called high cohesion is a code module only to complete a function, in the object-oriented, If only one class can do what it should do, and the realm that does not relate to it is to practice the principle of high cohesion, this class has only a single duty. We all know a word called "because of focus, so professional", an object if take too much responsibility, then doomed it to do nothing bad. Any good thing in the world has two characteristics, one is a single function, a good camera is definitely not the kind of machine sold in the TV shop has more than 100 kinds of functions, it is basically only photographic; the other is modular, good bikes are assembled cars, from damping forks, brakes to transmissions, All the parts can be disassembled and re-assembled, good ping-pong racket is not finished, it must be the bottom plate and rubber can be split and self-assembled, a good software system, each function module inside it should be easy to get other systems used, so as to achieve the goal of software reuse. ）
- Opening and closing principle: software entities should be open to extensions and closed for modification. (In an ideal state, when we need to add new functionality to a software system, we just need to derive some new classes from the original system, without having to modify any of the original lines of code.) To open and close there are two points: ① abstraction is the key, if there is no abstract class or interface system in a system without an extension point, ② package variability, the system of various variables encapsulated in an inheritance structure, if a number of variables mixed together, the system will become complex and chaotic, if not clear how to encapsulate the variability, You can refer to the chapter on bridge mode in the "Design pattern Refinement" book. ）
- Dependency reversal principle: interface-oriented programming. (This principle is straightforward and concrete is that when declaring a method's parameter type, the return type of the method, the reference type of the variable, use the abstract type as much as possible instead of the concrete type, because the abstract type can be replaced by any one of its subtypes, refer to the following Richter substitution principle.) ）
- Richter Replacement principle: The parent type can be replaced at any time by a subtype. (For the description of the Richter replacement principle, Ms Barbara Liskov's description is much more complicated than this, but it is simply that the subtype can be used where the parent type is used.) The Richter substitution principle can check whether the inheritance relationship is reasonable, if an inheritance relationship violates the Richter scale substitution principle, then the inheritance relationship must be wrong and the code needs to be refactored. For example, letting a cat inherit a dog, or a dog inheriting a cat, or letting a square inherit a rectangle is a false inheritance, because you can easily find a scenario that violates the Richter scale substitution principle. It is important to note that subclasses must be able to increase the ability of the parent class rather than reduce the ability of the parent class, because the child is more capable of analogy with the parent, and the ability to use a lot of objects as a less capable object is certainly not a problem. ）
- Interface Isolation principle: The interface should be small and dedicated, must not be chatty. (bloated interface is the pollution of the interface, since the interface represents the ability, then an interface should only describe a capability, the interface should also be highly cohesive.) For example, four arts should be designed as four interfaces, and should not be designed as an interface of four methods, because if designed as an interface in four methods, then this interface is very difficult to use, after all, four arts four is proficient in a few people, and if designed to four interfaces, will implement several interfaces, In this way, the likelihood that each interface is reused is very high. The interface in Java represents the ability, the representative Convention, the representative role, the correct use of the interface must be an important indicator of the level of programming. ）
- Synthetic aggregation multiplexing principle: use aggregation or synthetic relationship reuse code preferentially. (Through inheritance, the use of code is the object-oriented programming of the most abused things, because all textbooks are not an exception to the inheritance has been advocated to mislead the beginner, class and class between the simple say there are three relations, is-a relationship, has-a relationship, use-a relationship, respectively, representing the inheritance, Associations and dependencies. Among them, the association relationship according to its associated strength can be further divided into association, aggregation and synthesis, but plainly all are has-a relations, the synthetic polymerization principle is to express the priority to consider the has-a relationship rather than is-a relationship reuse code, reason why you can find 10,000 reasons from Baidu, need to explain is , even in the Java API there are many examples of abuse of inheritance, such as the properties class inherits the Hashtable class, the stack class inherits the vector class, these inheritance is obviously wrong, A better practice is to place a member of the Hashtable type in the Properties class and set its key and value to a string to store the data, and the stack class should also be designed to place a vector object in the Stack class to store the data. Remember: Do not inherit the tool class at any time, tools can be owned and can be used (has/use), rather than inherited. ）
- Dimitri Law: The Dimitri rule is also called the least knowledge principle, and an object should have as little understanding of other objects as possible. (Dimitri Law is simply how to do "low coupling", the façade mode and the mediator mode is the practice of the Dimitri Law.) For the façade mode can give a simple example, you go to a company to negotiate business, you do not need to understand how the company's internal operation, you can even know nothing about the company, go to the company at the entrance only need to find the front desk beauty, tell them what you want to do, they will find the right person to contact you, The beauty at the front desk is the façade of the company's system. Complex systems can provide users with a simple façade, Java web development as a front-end controller servlet or filter is not a façade, the browser does not know how to operate the server, but through the front-end controller can be based on your request to get the corresponding service. The mediator model can also give a simple example to illustrate, such as a computer, CPU, memory, hard disk, graphics card, sound card various devices need to cooperate to work well, but if these things are directly connected together, the computer cabling will be unusually complex, in this case, The motherboard appears as a mediator, connecting the devices together without needing to exchange data directly between each device, thus reducing the coupling and complexity of the system. The rule of Dimitri is to avoid dealing with strangers, if you really need to, find a friend of yours and let him deal with strangers. ）
Design patterns you've been familiar with or heard of and your views on design patterns
