Common design patterns in JAVA

This article mainly shares with you the common design patterns of JAVA. Friends who need it can take a look.

I have been exposed to design patterns very early. When I read some articles today, I found that I had some deviations in learning and understanding design patterns. Design patterns should serve specific scenarios and are code solution ideas summarized from previous experience. This solution idea considers how to make the coupling between codes lower and reduce redundancy, making the codes coupled. The purpose of lower degree is for better expansion of the program. The so-called better expansion refers to triggering as few changes as possible when the function is changed or expanded. Therefore, when learning design patterns, a good learning method should be to simulate the extension of the program to compare the differences between using the design patterns summarized by predecessors and the existing code. Only by truly realizing its advantages can we fully understand its essence. .

Creative Pattern

Creative pattern abstracts the instantiation process of objects, which helps a system be independent of how those objects are created, composed, and represented.

Abstract Factory Pattern

Abstract Factory Pattern is used to create factories with different product families. The so-called product family is worth multiple different objects. The values ​​of different objects are relative to objects that implement the same interface, so objects in the same product family definitely do not implement the same interface.

The Abstract Factory pattern includes 7 main roles, Class A abstract role and Class A concrete role (AbstractProductA, ProductA), Class B abstract role and Class B concrete role (AbstractProductB, ProductB), Abstract Factory (AbstractFactory) Provides two method interfaces for type A products and type B products. The concrete factory (ConcreteFactory) implements the two method interfaces of the abstract factory. The implementation of the two method interfaces depends on different products A and B (createProductA is derived from the implementation class of product A Select an implementation class from the implementation class, createProductB selects an implementation class from the implementation class of product B). Client relies on the specific implementation class of the abstract factory to produce product family products of a specific factory.

The abstract factory pattern implements the provision of product family factories for multiple products and realizes multi-dimensional combinations of multiple products. A typical example of product families is UnixButton and WindowsButton. Available from factory for different product combinations. From an expansion perspective, the concrete factory implements the abstract factory. If a new product family is needed, just implement another product family, realizing hot swapping. Comparing the factory model, a concrete factory faces a product, while an abstract factory faces a series of products.

Builder Pattern

The role of the builder pattern is to abstract the construction steps of an object, making it easy to rewrite an Object construction process.

The builder pattern includes 4 main roles, builder interface (Builder), concrete builder (ConcreteBuilder), product object (Product) and director class (Director). The construct method of the director class is responsible for calling multiple buildPart methods of the abstract builder for assembly. The Builder interface defines multiple partial construction processes, the buildPart() method, and the construction result method, retrieveResult() method, for concrete builders to implement. ConcreteBuilder implements partial construction methods and Result return method, the specific builder completes the corresponding assembly task, and uses retrieveResult to obtain the corresponding assembly result.

From a purpose perspective, the builder pattern implements the simplest implementation of different assembly methods for objects. The order of assembly is controlled by the director class, and the specific assembly tasks are distributed in the hands of different builders. The director class and abstract The aggregation relationship of builders makes the actual operation of product construction hot-swappable, making the specific implementation of the build easier to expand or replace. On the other hand, if you use the director class to directly operate the product to implement the product assembly process, and if you need to change the construction process, you must modify the director class, which is what we don't want to see.

Structural Pattern

Structural pattern focuses on how to assemble existing classes and design the interactions between them to achieve certain purposes, such as scalability and encapsulation.

Adapter pattern

The purpose of the adapter pattern is to convert the method interface of a class into another method interface that will be used by another client.

The adapter pattern contains three main roles, the target interface (Target) required by the client and its method sampleOperation(); the adapted class Adaptee, which is the actual executor; the adapter Adapter, which the Adapter inherits Target interface, and inherits Adaptee, Adapter's sampleOperation method calls Adptee's sampleOperation method. In fact, the method of calling the Adaptee class can be inherited or directly dependent. The former is called a class adapter and the latter is called an object adapter.

The adapter pattern implements compatibility conversion from one interface to another. There is nothing special about scalability.

Decorator mode

The decorator mode is also called the packaging mode. Its purpose is to dynamically extend the functionality of a class without changing the original inheritance relationship. The functions of the extended classes mentioned here can be changes to existing methods, or they can provide more methods.

The decorator pattern contains 4 main roles, the inheritance relationship that already exists in the system, the component interface (Component) and its implementation class (ConcreteComponent), and the decorator (Decorator) implements the component interface that depends on the concrete being decorated. Implementation class, its sampleOperation() method depends on the sampleOperation() method of the specific component class being decorated, and then the specific decorator (ConcreateDecorator) inherits from Decorator, and can add other methods or modify the corresponding sampleOperation method, thereby achieving different Change the original class and implement the same dynamic method expansion, and this expansion is transparent to the client.

From an extension perspective, Decorator replaces the position of the original ConCreteComponent and replaces it to complete the dynamic expansion of inheritance. Compared with directly inheriting from ConcreteComponent, this method has smaller dependencies on the objects it decorates. It can also be dynamically plugged and unplugged, and ConcreteComponent does not need to know the existence of decorative classes, eliminating the need to maintain complex class relationships.

A specific example of an application is the relationship between BufferInputStream and FileInputStream. InputStream is a Component, FileInputStream, ByteArrayInputStream, etc. are specific components. FilterInputStream is a decorator. BufferInputStream, etc. inherit from FilterInputStream and are specific decorators.

Agent mode

The purpose of the proxy mode is to provide a proxy for an object. The proxy object can enhance, modify or even delete the original Some functions.
Because the proxy mode is very widely used, the proxy mode has been described in detail in another blog and will not be redundant here.

Structural Pattern

Structural design pattern focuses on the distribution of responsibilities between classes or objects, and studies how multiple classes or objects can efficiently cooperate to complete a task.

Observer Pattern

The purpose of the Observer pattern is to implement a one-to-many dependency relationship, so that when the topic is updated, the update can be notified in a specific way. Topic bound observer.

The observer pattern contains 4 participants, subject interface and specific implementation subject (Subject, ConcreteSubject), observer and specific observer (Observer, ConcreateObserver). Observers are registered in the Subject through aggregation. Due to the dependency definition interface, specific topics can implement different notification strategies, and low-coupling dependencies can be achieved between specific observers and specific topics.
The dependency between the two can be established and released through the attach and detach methods. When the subject changes state, it can notify all observers through notifyObserver and call the update method of the corresponding observer.
From an expansion point of view, the advantage of the observer mode is that when adding a new observer, you only need to implement the observer interface, and then attach to the specific subject you want to monitor to add it; similarly, if you want to delete An observer in a subject only needs to call the attach method to implement hot swapping. If this design method is not adopted, the inability of either party to use the interface will cause difficulty in adding one party.

Mediator Pattern

The role of the intermediary pattern is to use an intermediary object to encapsulate the interaction of a series of objects, so that the interaction of each object does not require explicit interdependence. To put it simply, it is to convert the interaction between different objects from a many-to-many mesh association into a one-to-many star association.

The mediator pattern is constructed by four main roles. The mediator interface (Mediator) defines the public interaction method changed(); the concrete mediator (ConcreteMediator) implements the specific interaction method changed(), and obtains the required persistence. There is a reference to the colleague that needs to be communicated. The specific implementation of the changed() method depends on the held colleague reference; the colleague abstract class (Colleague) defines the association between the colleague interface and the mediator interface, and provides an interface method to obtain the mediator; concrete There may be multiple colleague implementation classes (ConcreteColleague), which mainly implement specific interactive operations. The interactive operations depend on the changed method of its associated mediator. As for why it has become a one-to-many relationship, judging from the relationship between the four roles above, each colleague holds a reference to a mediator, and each mediator holds references to all colleges.

The advantage of the mediator pattern is to decouple the interaction of complex system objects, so that when adding or deleting a college, only the intermediate mediator needs to be modified. The mediator can also be replaced by another specific mediator and replace the corresponding interactive behavior. The disadvantage is that as the number of colleagues who need to interact continues to increase, the number of specific intermediaries will continue to expand.

The above is the detailed content of Common design patterns in JAVA. For more information, please follow other related articles on the PHP Chinese website!