Shulou(Shulou.com)06/03 Report--

This article focuses on "case analysis of appearance patterns in Java design patterns". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "the case analysis of appearance patterns in Java design patterns".

Model motivation

After the appearance role is introduced, the user only needs to interact with the appearance role directly, and the complex relationship between the user and the subsystem is realized by the appearance role, thus reducing the coupling degree of the system.

Schema definition

Appearance pattern is a very frequently used structural design pattern, which simplifies the interaction between client and subsystem by introducing an appearance role, and provides a unified entrance for complex subsystem invocation. reduce the coupling between the subsystem and the client, and the client call is very convenient.

Appearance mode, also known as facade mode, is a kind of object structure mode. Appearance pattern is a concrete implementation of Dimitt rule, which can reduce the complexity of the original system and the coupling between customer class and subsystem by introducing a new appearance role.

Pattern structure

Role

Facade (appearance role): its methods can be called on the client, and the functions and responsibilities of the relevant (one or more) subsystems can be known in the appearance role; under normal circumstances, it delegates all requests from the client to the corresponding subsystem and passes them on to the corresponding subsystem object for processing.

SubSystem (subsystem role): there can be one or more subsystem roles in a software system, and each subsystem may not be a separate class, but a collection of classes, which implements the functions of the subsystem; each subsystem can be called directly by the client or by the appearance role, which handles requests passed by the appearance class The subsystem is not aware of the appearance, and for the subsystem, the appearance role is just another client.

The purpose of the appearance pattern is not to add new functional interfaces to the subsystem, but to reduce the external interaction with multiple modules within the subsystem and loose coupling, so that the external can use the subsystem more easily.

The essence of appearance pattern is to encapsulate interaction and simplify invocation.

Mode analysis

According to the "single responsibility principle", dividing a system into several subsystems in software helps to reduce the complexity of the whole system. A common design goal is to minimize the communication and interdependence between subsystems. One of the ways to achieve this goal is to introduce an appearance object, which provides a simple and single entrance for subsystem access.

Appearance pattern is also the embodiment of "Demeter rule". By introducing a new appearance class, the complexity of the original system can be reduced and the coupling degree between customer class and subsystem class can be reduced.

The appearance mode requires that the external and internal communication of a subsystem is carried out through a unified appearance object, and the appearance class separates the client from the internal complexity of the subsystem, so that the client only needs to deal with the appearance object. without having to deal with many objects inside the subsystem.

The purpose of appearance mode is to reduce the complexity of the system.

The appearance mode improves the convenience of the client to a great extent, so that the client does not need to care about the working details of the subsystem, but can call the relevant functions through the appearance role.

Typical appearance role code public class Facade {private SubSystemA obj1 = new SubSystemA (); private SubSystemB obj2 = new SubSystemB (); private SubSystemC obj3 = new SubSystemC (); public void method () {obj1.method (); obj2.method (); obj3.method ();}} appearance mode example and parsing example 1: power master switch

Now look at an example of a power master switch to further illustrate the appearance mode. For ease of use, a power master switch can control the start and turn off of four lights, a fan, an air conditioner and a TV set. Through the power supply master switch, all the above electrical equipment can be controlled at the same time, and the appearance mode is used to design the system.

/ / create a singleton object static {instance=new Fan ();} public static Fan getInstance () {return instance;} public void on () {System.out.println ("Fan on") in the subsystem role public class Fan {instance=new Fan () {} private static Fan instance; / / static code block } public void off () {System.out.println ("fan off");}} / / subsystem role public class Light {/ / static constant private static Light instance=new Light (); / / Constructor privatizes private Light () {}; / / there are static methods that return an instance object public static Light getInstance () {return instance } public void on () {System.out.println ("light on");} public void off () {System.out.println ("light off");}} / / appearance character public class GeneralSwitchFaced {private Light light; private Fan fan; public GeneralSwitchFaced () {light=Light.getInstance (); fan=Fan.getInstance () } public void on () {light.on (); fan.on ();} public void off () {light.off (); fan.off ();}} / / Test public class Test {@ org.junit.Test public void test () {GeneralSwitchFaced faced=new GeneralSwitchFaced (); faced.on (); faced.off ();}}

Example 2: file encryption

A system needs to provide a file encryption module, and the encryption process includes three operations, namely, reading the source file, encrypting and saving the encrypted file. Reading and saving files are implemented using streams, these three operations are relatively independent, and their business code is encapsulated in three different classes. Now we need to provide a unified encryption appearance class, users can directly use the encryption appearance class to complete the file reading, encryption and save three operations, without the need to interact with each class, using the appearance pattern to design the encryption module.

Through a method of the appearance role, three independent operation processes are encapsulated, that is, the encryption process of the file is encapsulated in the file encryption method of the appearance role, and the customer can encrypt the file by calling this method. There is no need to call three separate operations one by one

Advantages and disadvantages of the model

Shielding subsystem components to customers reduces the number of objects handled by customers and makes the subsystem easier to use. By introducing the appearance pattern, the customer code becomes simple and there are few objects associated with it.

The loose coupling relationship between the subsystem and the customer is realized, so that the component change of the subsystem will not affect the client class that invokes it, and only needs to adjust the appearance class.

It reduces the compilation dependency in large software systems and simplifies the migration process of the system between different platforms, because compiling one subsystem generally does not need to compile all other subsystems. The modification of one subsystem has no effect on the other subsystems, and the changes within the subsystem will not affect the appearance object.

It only provides a unified access to the subsystem and does not affect the user's direct use of the subsystem class.

Shortcoming

The customer's use of the subsystem class is not well restricted, and the variability and flexibility are reduced if there are too many restrictions on the customer's access to the subsystem class.

Without introducing the abstract appearance class, adding a new subsystem may need to modify the source code of the appearance class or the client, which violates the "open-close principle".

Mode applicable environment

You can use the appearance pattern when you want to provide a simple interface to a complex subsystem. This interface can meet the needs of most users, and users can also access the subsystem directly beyond the appearance class.

There is a great dependency between the client program and multiple subsystems. The appearance class is introduced to decouple the subsystem from the customer and other subsystems, which can improve the independence and portability of the subsystem.

In the hierarchical structure, the appearance pattern can be used to define the entrance of each layer in the system, and there is no direct relationship between the layers, but through the appearance class to establish the connection to reduce the coupling between the layers.

Typical application of source code analysis appearance pattern (1) appearance pattern is applied to JDBC database operation public class JDBCFacade {private Connection conn=null; private Statement statement=null; public void open (String driver,String jdbcUrl,String userName,String userPwd) {. } public int executeUpdate (String sql) {. } public ResultSet executeQuery (String sql) {. } public void close () {. }} (2) Session appearance pattern is the application of appearance pattern in Java EE framework

Pattern extension A system has multiple appearance classes

In appearance mode, only one appearance class is usually required, and this appearance class has only one instance, in other words, it is a singleton class. In many cases, in order to save system resources, appearance classes are generally designed as singleton classes. Of course, this does not mean that there is only one appearance class in the whole system, multiple appearance classes can be designed in one system, and each appearance class is responsible for interacting with some specific subsystems and providing corresponding business functions to users.

Don't try to add new behavior to the subsystem through appearance classes

It is wrong not to add new behavior to the subsystem by inheriting an appearance class. The purpose of the appearance pattern is to provide a centralized and simplified communication channel for the subsystem, rather than adding new behavior to the subsystem. The increase of new behavior should be realized by modifying the original subsystem class or adding a new subsystem class. Can not be achieved through the appearance class.

Appearance pattern and Demeter's Law

The appearance pattern creates an appearance object, which minimizes the number of partners belonging to a subsystem involved by the client, so that the interaction between the client and the objects within the subsystem is replaced by the appearance object. The appearance class acts as a "third party" between the client class and the subsystem class, reducing the coupling between the client class and the subsystem class. The appearance pattern is a powerful weapon to achieve code refactoring in order to meet the requirements of the Dimitt rule.

The introduction of Abstract appearance Class

The biggest disadvantage of appearance pattern is that it violates the "opening and closing principle". When adding new subsystems or removing subsystems, you need to modify appearance classes, which can be solved to some extent by introducing abstract appearance classes. the client programming for abstract appearance classes. For the new business requirements, the original appearance class is not modified, but a new specific appearance class is added, and the new specific appearance class is associated with the new subsystem object. at the same time, the purpose of not modifying the source code and replacing the appearance class is achieved by modifying the configuration file.

At this point, I believe you have a deeper understanding of the "case analysis of appearance patterns in Java design patterns". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.