The façade mode of Java and pattern
In the book "Java and Patterns" of Dr. Shanhong, this is how the façade (facade) pattern is described:
façade mode is the structure pattern of an object, and communication between an external and a subsystem must be done through a unified façade object. Façade mode provides a high-level interface that makes subsystems easier to use.
Examples of hospitals
Modern software systems are more complex, and a common way for designers to deal with complex systems is to divide and divide a system into smaller subsystems. If the hospital as a subsystem, according to departmental functions, the system can be divided into registered, outpatient, pricing, laboratory, charge, take medicine and so on. It is not an easy thing for a patient to have to deal with these departments, just as a subsystem's client is dealing with the various classes of a subsystem.
First, the patient must be registered before the clinic. If the doctor requests a test, the patient must first pricing and then pay the fee before he can go to the laboratory to do the test. Go back to the outpatient room after the test.
Describing the patient's experience in the hospital, the box on the map represents the hospital.
The way to solve this inconvenience is to introduce the façade mode, the hospital can set up a receptionist's position, the receptionist is responsible for registering, pricing, payment, take medicine and so on. This receptionist is the embodiment of the façade pattern, the patient only contact the receptionist, the receptionist and the various departments to deal with.
the structure of the façade pattern
The façade mode does not have a generalized class diagram description, and the best description method is actually illustrated with an example.
Because the layout of the façade pattern is too abstract, make it slightly more specific. Assuming that there are three modules in the subsystem, namely Modulea, Moduleb, and Modulec, each with an example method, the overall structure of the example is as follows:
In this object graph, there are two characters:
façade (facade) Role:The client can invoke the method of this role. This role is aware of the functions and responsibilities of the related (one or more) subsystems. Under normal circumstances, this role will delegate all requests from the client to the appropriate subsystem.
subsystem (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 (such as the above subsystem is composed of Modulea, Moduleb, Modulec three classes of a combination of）。 Each subsystem can be called directly by the client or by a façade role. Subsystems do not know the presence of the façade, for the subsystem, the façade is just another client only.
Source
classes in the subsystem role:
public class Modulea { //schematic method public void TestA () { System.out.println ("Call TestA method in Modulea");} }
public class Moduleb { //schematic method public void Testb () { System.out.println ("Call Testb method in Moduleb");} }
public class Modulec { //schematic method public void Testc () { System.out.println ("Call testc method in Modulec");} }
façade role class:
public class Facade { //schematic method, which satisfies the functionality required by the client public void Test () { Modulea a = new Modulea (); A.testa (); Moduleb B = new Moduleb (); B.testb (); Modulec C = new Modulec (); C.TESTC (); }}
Client Role classes:
public class Client {public static void Main (string[] args) { facade facade = new facade (); Facade.test (); }}
Facade class is actually equivalent to a, B, C module appearance interface, with this facade class, then 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 system, and even do not need to know the existence of a, B, C module, The client only needs to interact with the facade class so that the decoupling of the A, B, and C modules in the client and subsystem is better implemented, making it easier for the client to use the system.
implementation of façade mode
One additional benefit of using façade mode is the ability to selectively expose methods. The methods defined in a module can be divided into two parts, part of which is used externally to the subsystem, and part of the internal modules of the subsystem that are used when calling each other. With the facade class, the method used to invoke each other within the subsystem is not exposed to the external subsystem.
For example, define a, B, and C modules as follows.
public class Module { /** * Provides a method for external use of the subsystem * /public void A1 () {}; /** * Method used by the internal modules of the subsystem when calling each other * /public void A2 () {}; public void A3 () {};}
public class Moduleb { /** * Provides a method for external use of the subsystem * /public void B1 () {}; /** * Method used by the internal modules of the subsystem when calling each other * /public void B2 () {}; public void B3 () {};}
public class Modulec { /** * Provides a method for external use of the subsystem * /public void C1 () {}; /** * Method used by the internal modules of the subsystem when calling each other * /public void C2 () {}; public void C3 () {};}
public class Modulefacade { Modulea a = new Modulea (); Moduleb B = new Moduleb (); Modulec C = new Modulec (); /** * These are the methods provided by the A, B, and C modules to the external subsystem */public void A1 () { a.a1 () } public void B1 () { b.b1 (); } public void C1 () { c.c1 (); }}
This defines a modulefacade class that effectively masks internal details, so that when the client calls the module class, it discovers some methods that do not need to be known. such as the A2 () and A3 () methods do not need to let the client know, otherwise exposing the internal details, but also to confuse the client. For the client, he may have to think about what the A2 () and A3 () methods are used for? In fact, the A2 () and A3 () method is the interaction between the internal modules, the original is not external to the subsystem, so simply do not let the client know.
a system can have several façade classes
In façade mode, typically only one façade class is required, and this façade class has only one instance, in other words, it is a singleton class. Of course this does not mean that there is only one façade class throughout the system, but only one façade class for each subsystem. Or, if a system has several subsystems, each subsystem has a façade class, the whole system can have a number of façade classes.
Add new behavior to subsystems
Beginners often assume that it is wrong to add new behavior to a subsystem by inheriting a façade class. The façade mode is intended to provide a centralized and streamlined communication pipeline for the subsystem, rather than adding new behavior to the subsystem. For example, a receptionist in a hospital is not a paramedic, and a receptionist cannot provide medical care for a patient.
Advantages of Façade mode
Advantages of the façade mode:
loosely coupled
The façade mode is loosely coupled between the client and subsystem, allowing the modules inside the subsystem to be more easily extended and maintained.
Simple to use
The façade mode makes the subsystem more easy to use, the client no longer needs to understand the implementation within the subsystem, and does not need to interact with the modules inside the many subsystems, just interact with the façade class.
better partitioning of access levels
By using facade wisely, you can help us to better classify the level of access. Some methods are external to the system, and some methods are used internally by the system. The ability to expose external functionality to the façade, which makes it easy for clients to use and hide internal details well.
The use of façade mode in Tomcat
There are a lot of façade patterns in Tomcat because there are many different components in Tomcat, each of which communicates 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 façade mode.
Here is the façade mode used on request:
Anyone who has used a servlet knows that, in addition to having a corresponding configuration in Web. XML, it is necessary to inherit an abstract class called HttpServlet, and rewrite the Doget and Dopost methods (and, of course, just rewrite the service method).
public class Testservlet extends HttpServlet {public void doget (HttpServletRequest request, HttpServletResponse Response) throws Servletexception, IOException { this.dopost (request, response); } public void DoPost (HttpServletRequest request, httpservletresponse response) throws Servletexception, IOException { }}
It can be seen that the doget and Dopost methods have two parameters, the parameter type is interface HttpServletRequest and interface HttpServletResponse, then what is the true type passed from Tomcat? By debugging, you will find that there are many methods in Tomcat before you actually call the Testservlet class. As shown
Notice the class in the Red Box circle, and the Invoke method 225 line code in the Standardwrappervalue class is as follows:
Filterchain.dofilter (Request.getrequest (), Response.getresponse ());
In the Standardwrappervalue class, there is no Dofilter method that directly passes the request object and the response object to the Applicationfilterchain class. The Requestfacade and Responsefacade objects are passed, why do you say, look at the request.getrequest () and Response.getresponse () method to the truth.
Request Class
Public HttpServletRequest getrequest () { if (facade = = null) { facade = new Requestfacade (this); } return facade; }
Response class
Public HttpServletResponse GetResponse () { if (facade = = null) { facade = new Responsefacade (this); } return (facade); }
You can see that their return is a façade class of their own, so what good is this?
Many of the methods in the request object are used when the internal components interact with each other, such as Setcomet, Setrequestedsessionid, etc. (not listed here). These methods are not exposed externally, but must be set to public because they also need to be used interactively with internal components. The best solution is to use a facade class that masks the methods used to interact with the internal components and only provides methods of interest to external programs.
If you do not use the facade class, the request object and the response object are passed directly. Programmers familiar with the internal workings of the container can then convert ServletRequest and Servletresponse objects down to request and response, and invoke their public methods. For example, the request object, you can call Setcomet, Setrequestedsessionid and other methods, which will jeopardize security.
"Design mode"-Façade mode
