Java design mode 11: Appearance mode

Appearance mode

The appearance pattern is the structure mode of the object, and the communication between the external and a subsystem must be done through a unified appearance object . Appearance mode is a high-level interface that makes subsystems easier to use.

Examples of hospitals

Modern software systems are more complex. If the hospital is compared to a subsystem, according to departmental functions, the system is divided into registered, outpatient, pricing, laboratory, charge, take medicine and so on. It's not easy for a doctor to deal with these departments, just as a subsystem's client is dealing with the various classes of a subsystem.

The way to solve this inconvenience is to introduce the appearance mode, the hospital can set up a receptionist's position, the receptionist is responsible for registering, pricing, payment, take medicine and so on. The patient only needs to contact the receptionist and the receptionist will deal with each department.

Structure of the appearance pattern

The structure of the appearance pattern can be expressed like this:

In this diagram, two roles are represented:

1. Appearance role

The client invokes the method of this role. This role is aware of the functions and responsibilities of the relevant subsystems, which, under normal circumstances, delegate all requests from the client to the subsystem of the response

2. Subsystem role

You can have 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 directly by the skin role. Subsystems do not know the existence of the appearance of the role, for the subsystem, the appearance is just another client only

Example of an appearance pattern

Simulation of three subsystems Modulea, Moduleb, Modulec:

 Public class modulea{    publicvoid  TestA ()    {        System.out.println (" Call the Testa method in module ");}    }

 Public class moduleb{    publicvoid  testb ()    {        System.out.println (" Call the Testb method in module ");}    }

 Public class modulec{    publicvoid  TESTC ()    {        System.out.println (" Call the Testc method in module ");}    }

To simulate a skin object:

 Public class facade{    publicvoid  Test ()    {        new  Modulea ();        Ma.testa ();         New Moduleb ();        Mb.testb ();         New Modulec ();        MC.TESTC ();    }}

Write a client to invoke the appearance of the role:

 Public Static void Main (string[] args) {    new  facade ();    Facade.test ();}

The result of the operation is obvious:

Call the Testa method in module call the Testb method in module to call the TESTC method in module

In this way, the client does not need to personally call the subsystem of A, B, C module, do not need to know the implementation details of the internal system, or even need not know the existence of module A, module B, module C, only need to interact with the facade class, so as to better achieve the client and subsystem of the three modules decoupling, Make it easier for clients to use subsystems.

In addition, defining an appearance class can also effectively mask the internal details. Because there are methods in the subsystem that interact with each other in the module, there is no need for external calls. If you call the subsystem's class method directly, there will be some methods that do not need to be known by the client, which exposes the internal details and confuses the client. The appearance class is not the same, you can only provide the client with those subsystems to external use of methods.

Application and interpretation of appearance pattern in Java

There are many scenarios in Tomcat that are used in appearance mode, because Tomcat has many different components, each of which needs to communicate with each other, but does not expose its own internal data too much to other components. It's a good way to isolate data in a visual mode, such as using the appearance pattern on request:

such as the Servlet,doget and Dopost methods, the parameter type is the interface HttpServletRequest and the interface HttpServletResponse, then what is the true type passed over in Tomcat?

The experience with debugging Java Web Projects will certainly reveal that there are many tomcat methods before actually invoking the servlet. Decompile the Javaee.jar package and you'll see that the actual types of request and response passed to Tomcat are:

See that the return is a facade class. Because many of the methods in the request class are interactive between components, such as Setcomet, Setreuqestedsessionid, and so on, these methods are not publicly available, but must be set to public because they also interact with internal components. The best solution is to use a facade class to mask the interaction between the internal components, providing only the methods that the external program will use.

If you do not use facade, the direct delivery is httpservletrequest and HttpServletResponse, Developers who are familiar with the internal workings of the container can transform ServletRequest and servletresponse down to HttpServletRequest and HttpServletResponse respectively, thus having a security problem.

Advantages of the Appearance mode

There are several advantages to the appearance mode:

1. Loose coupling

The appearance mode is loosely coupled between the client and subsystem, making it easier to extend and maintain the modules inside the subsystem

2. Easy to use

The client does not need to understand the internal implementation of the system, and does not need to interact with many of the modules inside the module, only need to interact with the appearance of the class can be

3. Better division of hierarchy

By using facade wisely, you can help us to better divide the hierarchy. Some methods are internal to the system, some methods are external, the need to expose to the external functions of the facade, so that both the convenience of the client, but also good to hide the internal details

Java design mode 11: Appearance mode