Design Pattern Concept
Design Patterns are a set of repeated, well-known, categorized and catalogued summaries of good code design experiences. Design patterns are used to reuse code, make code easier to understand, and ensure code reliability. The use of design patterns is beneficial to others, to themselves and to the system. Design patterns make code compilation truly engineering and are the cornerstone of software engineering, enabling people to reuse successful designs and architectures more easily and conveniently. Representing technologies as design patterns also makes it easier for new system developers to understand their design ideas. Design patterns provide us with a set of reusable object-oriented techniques.
Reusable object-oriented software systems are generally divided into two categories: application toolkits and frameworks. The specific software we usually develop is an application program. The basic classes of Java belong to the toolbox, and the framework is a group of cooperative classes that constitute the reusable design of a specific software. Frameworks usually define design parameters such as the overall structure of the application, classes and object relationships, so that specific application implementations can focus on specific details of the application itself. The framework mainly records common design decisions in software applications and emphasizes design reuse. Therefore, design patterns must be used in mature framework design. If you are familiar with these design patterns, it will help you understand the framework structure, so that you can quickly grasp the structure of the framework. .
The principle implemented by the Java design pattern is: interface-oriented programming, not implementation-oriented. Its goal principle is to reduce coupling and increase flexibility.
Design Pattern Elements
Describing a design pattern requires a certain format, usually in GoF format:
- pattern name
Design patterns have names that succinctly describe the problems, solutions, and effects of design patterns. A schema must have a meaningful, short and precise name. A good design pattern facilitates the exchange of ideas between designers, abstract discussions, and research on design results. Once you find an appropriate schema name, you can discuss schemas and use them when writing documentation.
problem
Patterns tell when patterns should be used. It explains the cause and effect of the problem. It may describe a specific design problem, such as how to express an algorithm with an object, or it may describe a class or object structure that is not designed flexibly. Sometimes the questions section includes a list of prerequisites that must be met to use the schema.
- solution
Describes the components of the design, their interrelationships and their respective responsibilities and ways of working together. A pattern is like a template that can be applied in many different situations, so the solution does not describe a specific and concrete design or implementation, but provides an abstract description of the problem and how to combine elements (classes or objects) with a general meaning. combination) to solve this problem.
- effect (consequence)
Describes the effects of pattern application and trade-offs in using patterns. Effects are used to model the pros and cons of design patterns. It is often an important factor to measure whether a pattern is available or not, and it plays an important role in the choice of design patterns. Software effects mostly focus on the measurement of time and space, expressing language and implementation issues. Because reuse is one of the elements of object-oriented design, design pattern effects include their effects on the flexibility, extensibility, and portability of a system. Explicitly listing these effects has great implications for understanding and evaluating these patterns. help.
- examples
Use one or more illustrative applications to illustrate a specific real-world environment and how the pattern is applied to the environment, changes the environment, and gives the final state of the pattern after use. Examples help to understand the use and applicability of design patterns.
- resulting context
The state after a design pattern is applied to the system. The final state environment includes the good and bad outcomes of the pattern, as well as other problems contained in the new state and other related patterns that may be involved. The end-state environment is the end-state condition and possible side effects of the pattern. Describing the end-state environment can help compare the differences and connections between the end-state environment and the initial environment.
- reasoning
Reasoning explains the steps, rules of the pattern, and how the pattern as a whole solves the pattern in a particular way. Reasoning lets users know if a pattern works, why it works, and what the advantages of using this pattern are. Describes the external, visible structure and behavior of the pattern, while inference gives the pattern's deep structure and key mechanisms below the surface of the system.
- other related patterns
Describe the static and dynamic relationships of this schema and other schemas in existing systems. The initial environment and the final state of the related mode are often compatible. These modes may be the predecessor modes of this mode, and the modes are related.
- known uses
A known application is an example of the emergence and application of an existing system pattern that helps to demonstrate that the pattern is indeed a viable answer to a recurring problem. Known applications are often used as teaching materials.
Design Pattern Classification
Commonly used design patterns can be summarized into 23 types, which can be divided into three types according to their characteristics:
- Creation
A creational pattern is a pattern used to create objects, abstracting the process of instantiation and helping a system to be created independently of its associated objects. Two main functions:
- Encapsulate the information of concrete classes used by the system;
- Hides how instances of classes are created and organized. The outside world only knows their common interface for these objects, but not the specific implementation details.
The role of the creational pattern can be summarized in the following two points:
- Encapsulating the creation logic is not just as simple as creating an object;
- Encapsulation creates logical changes, and the client code is not modified as much as possible, or is modified as little as possible.
Common creational design patterns include the following:
- Singleton pattern: A class has only one instance, and it instantiates itself and provides this instance to the entire system.
- Factory method pattern (factory pattern): In the factory method pattern, the factory class is an abstract class, and the actual creation work is done by its subclasses. The purpose of the factory method is to define a factory interface for creating product objects, defer the actual creation work to subclasses, and emphasize 'single object' changes.
- Abstract factory pattern: Abstract factory pattern is the most abstract and general form of all factory patterns. The abstract factory can provide an interface to the client, so that the client can create multiple product objects without specifying the specific type of the product, emphasizing the change of 'series objects'.
- Builder pattern: Moves the logic of constructing object instances to the outside of the class, and defines the construction logic of the class outside the class. It separates the construction process of a complex object from the representation of the object, and its direct effect is to simplify a complex object into a relatively simple target object, emphasizing the construction process of the product.
- Prototype pattern: Like the factory pattern, the prototype pattern also hides the object creation work from the client, but instead of constructing a new object by instantiating a class, the prototype pattern generates a new object by copying an existing object .
- structural
Structural pattern discusses the structure of classes and objects, it uses inheritance mechanism to combine interfaces or implementations (class structural pattern), or to achieve new functionality by combining some objects (object structural pattern). These structural patterns share a great deal of similarity in some respects, but differ in their focus. Common structural design patterns are as follows:
- Proxy mode (proxy): Provide a proxy for other objects to control access to this object.
- Decorator: Dynamically add some additional responsibilities to an object. In terms of adding functionality, the decorator pattern is more flexible than subclassing.
- Adapter pattern (adapter): the interface of one class is transformed into another interface expected by the client, so that two classes that could not work together due to the interface mismatch can work together.
- Composite mode (composite): Also known as composite mode, the objects are combined into a tree structure to represent the "part-whole" hierarchical structure, so that users can use a single object and a composite object with consistency.
- Bridge mode (bridge): Also known as the bridge mode, the abstraction and implementation are decoupled, so that the two can be changed independently.
- Facade mode (facade): also called facade mode, requires that the communication between the external and internal of a subsystem must be carried out through a unified object, the facade mode provides a high-level interface, making the subsystem easier to use.
- Flyweight: It is an important implementation of pooling technology. The use of shared objects can effectively support a large number of fine-grained objects.
- behavioral
Behavioral design patterns focus on the behavior of objects and are used to solve the problem of connection between objects. Common behavioral design patterns are as follows:
- Template method pattern (template method): Define the framework of an algorithm in an operation, and defer some steps to subclasses, so that subclasses can redefine some specific steps of an algorithm without changing the structure of the algorithm.
- Command mode (command): It is a highly cohesive mode that encapsulates a request into an object, thereby parameterizing the client with different requests, queuing the request or recording the request log, which can provide command revocation and recovery functions .
- Chain of responsibility pattern (chain of responsibility): Give multiple objects a chance to process the request, thereby avoiding the coupling relationship between the sender and receiver of the request. Chain these objects together and pass the request down the chain until an object handles it.
- Strategy pattern (strategy): Also called policy pattern, defines a set of algorithms, encapsulates each algorithm, and makes them interchangeable.
- Iterator pattern (iterator): Provides a way to access the elements in a container object without exposing the internal details of the object.
- 中介者模式（mediator）：用一个对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
- 观察者模式（observer）：也叫发布订阅模式，定义对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
- 备忘录模式（memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
- 访问者模式（visitor）：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下，定义作用于这些元素的新的操作。
- 状态模式（state）：当一个对象内在的状态改变时允许其改变行为，这个对象看起来像改变了其类型，状态模式的核心是封装，状态的变更引起行为的变更。
- 解释器模式（interpreter）：给定一门语言，定义它文法的一种表示，并定义一个解释器，该解释器使用该文法表示，来解释语言中的句子。
设计模式小结
- 设计一个模式的过程就是将问题抽象化，忽略不重要的细节后发现问题的本质，并找到普遍使用的解决方案的过程。
- 设计模式起源于建筑设计学。
- 设计模式的基本要素有：名字、问题、初始环境、举例、末态环境、推理、其它有关模式、已知应用。
- 设计模式主要有23种，可以将这些模式分为三大类型：创建型、结构型和行为型。
- 创建型包括：单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。
- 结构型包括：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式和享元模式。
- 行为型包括：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式和解释器模式。