23 design modes (8) Java appearance mode

23 design patterns Part 8: Java appearance pattern

definition:

Provide a consistent interface for a set of interfaces in the subsystem. The facade pattern defines a high-level interface, which makes the subsystem easier to use.

Role:

1. Facade role: the client can call the methods of this role. This role is aware of the functions and responsibilities of the relevant subsystems. Under normal circumstances, this role will delegate all requests sent from the client to the corresponding subsystem.

2. Subsystem role: there can be one or more subsystems at the same time. Each subsystem is not a separate class, but a collection of classes. Each subsystem can be called directly by the client or by the appearance role. The subsystem does not know the existence of the appearance role. For the subsystem, the appearance role is just another client.

Sketch Map:

Example:

1. Subsystem role, consisting of several classes

2. Appearance role class

3. Client test method

The facade class is actually equivalent to the appearance interface of the subclass class in the subsystem. With this facade class, the client does not need to call those specifically implemented subclasses in the subsystem, nor do they need to know the implementation details inside the system, nor do they even need to know the existence of these subclasses. The client only needs to interact with the facade class, Thus, the decoupling between the client and the specific classes in the subsystem is better realized, and the client can use the system more easily. At the same time, defining a facade class in this way can effectively shield the internal details, so as to prevent the client from finding some methods that it does not need to know when calling the module class. In the above code, method 2 in all my subclasses is a method called by method 1, which is matched with method 1. They do not need to be called by the client and have certain confidentiality, so that the client can not know when using the appearance mode.

advantage:

The loose coupling relationship between subsystem and client is realized. The client shields the subsystem components, reduces the number of objects to be processed by the client, and makes the subsystem easier to use.

Applicable scenarios:

In the early stage of design, different layers should be consciously separated and appearance patterns should be established between layers. In the development stage, the subsystem becomes more and more complex, and the appearance mode is added to provide a simple call interface. When maintaining a large legacy system, it may be very difficult to maintain and expand, but it also contains very important functions. Develop an appearance class for it so that the new system can interact with it.

Appearance mode summary:

1. Appearance mode provides a simple interface for complex subsystems, and does not add new functions and behaviors to subsystems. 2. The appearance pattern realizes the loose coupling relationship between the subsystem and the client. 3. The appearance pattern does not encapsulate the classes of the subsystem, but only provides a simple interface. It does not restrict customers from using subsystem classes if required by the application. Therefore, it can flexibly choose between system ease of use and universality. 4. The appearance pattern focuses on simplifying the interface. It looks at the whole system from the architecture level rather than the level of a single class.

Transferred from: Java confidant

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.