Design pattern (Designpattern) is a set of repeated use, most people know, catalogued, the summary of code design experience.
The above is the explanation in Baidu, to explain the meaning of this simple sentence, a few key words.
Repeated use
: This does not need to be explained too much, the design pattern is used too much, there are many patterns in the last series of spring source code, the more profound memory is template pattern, proxy pattern, singleton pattern, factory pattern and so on.
Classification and cataloging
: that is, you can find some characteristics to divide these design patterns, so as to classify them.
Code design experience
: The summary of design experience, that is to say, the design pattern, is the routine summed up from experience in order to guide the design.
There is also a saying that a design pattern is a series of methods that can solve a problem in a specific scenario. In fact, I think this explanation is more appropriate.
According to the reference book on design patterns, there are 23 design patterns in total. These patterns can be divided into three main categories:
Creational Patterns,
Structural Patterns,
Behavioral Patterns
creative mode
These design patterns provide a way to hide the creation logic while creating objects, rather than instantiating objects directly using new operators. This makes the program more flexible in deciding which objects need to be created for a given instance.
- Factory Pattern
- Abstract Factory Pattern
- Singleton Pattern
- Builder Pattern
- Prototype Pattern
Factory pattern: Define an interface for creating an object, let its subclasses decide which factory class to instantiate, and the factory pattern delays the creation process to subclasses.
Abstract Factory Pattern: Provides an interface to create a series of related or interdependent objects without specifying their concrete classes.
Singleton pattern: guarantees that a class has only one instance and provides a global access point to it.
Builder Pattern: Decouples a complex build from its representation so that the same build process can create different representations.
Prototype pattern: Use prototype instances to specify the kinds of objects to create, and create new objects by copying these prototypes.
Structural Pattern
These design patterns focus on the composition of classes and objects. The concept of inheritance is used to compose interfaces and to define the way in which composite objects obtain new functionality.
- Adapter Pattern
- Bridge Pattern
- Filter pattern (Filter, Criteria Pattern)
- Composite Pattern
- Decorator Pattern
- Facade Pattern
- Flyweight Pattern
- Proxy Pattern
Adapter pattern: Convert the interface of a class into another interface that the client wants. The adapter pattern enables classes to work together that would otherwise not work together due to incompatible interfaces.
Bridge Pattern: Separating the abstract part from the implementation part so that they can both change independently.
Filter Pattern: This pattern allows developers to filter a set of objects using different criteria, connecting them in a decoupled manner through logical operations
Composition Mode: Groups objects into a tree structure to represent a "part-whole" hierarchy. The composite mode allows users to use individual objects and composite objects consistently.
Decorator Pattern: Dynamically add some additional responsibilities to an object. The decorator pattern is more flexible than subclassing in terms of adding functionality.
Facade Pattern: Provides a consistent interface for a set of interfaces in a subsystem. Facade pattern defines a high-level interface that makes the subsystem easier to use.
Flyweight Pattern: Use sharing techniques to efficiently support a large number of fine-grained objects.
Proxy mode: Provides a proxy for other objects to control access to this object.
behavioral model
These design patterns specifically focus on communication between objects.
- Chain of Responsibility Pattern
- Command Pattern
- Interpreter Pattern
- Iterator Pattern
- Mediator Pattern
- Memento Pattern
- Observer Pattern
- State Pattern
- Null Object Pattern
- Strategy Pattern
- Template Pattern
- Visitor Pattern
Chain of Responsibility Pattern: Avoid coupling request sender and receiver, make it possible for multiple objects to receive the request, connect these objects into a chain, and pass the request along the chain until an object handles it.
Command Pattern: Encapsulates a request as an object, allowing you to parameterize clients with different requests.
Interpreter pattern: Given a language, define its grammatical representation, and define an interpreter that uses that identity to interpret sentences in the language.
Iterator pattern: Provides a way to sequentially access the elements of an aggregate object without exposing the object's internal representation.
Mediator pattern: A mediator object is used to encapsulate a series of object interactions. The mediator makes the objects do not need to refer to each other explicitly, so that the coupling is loose, and the interaction between them can be changed independently.
Memento Pattern: Capture the internal state of an object and save this state outside the object without breaking encapsulation.
State mode: Define a one-to-many dependency between objects. When the state of an object changes, all objects that depend on it are notified and automatically updated.
Empty Object Pattern: In Empty Object Pattern, we create an abstract class that specifies various operations to be performed and an entity class that extends this class, and also create an empty object class that does not implement any implementation of the class, the empty object class Will be used seamlessly wherever nulls need to be checked.
Strategy pattern: Define a series of algorithms, encapsulate them one by one, and make them interchangeable.
Template Pattern: Define the skeleton of an algorithm in an operation, while deferring some steps to subclasses. Template methods allow subclasses to redefine certain steps of an algorithm without changing its structure.
Visitor pattern: mainly separates data structures from data operations
Any design pattern that has no practical application scenarios is playing hooligans. Learning design patterns is not only for comprehending its essence, but also for applying and adapting in practical design. Next, you will need to break each