Façade mode

Reprint: http://blog.csdn.net/jason0539/article/details/22775311

Provides a consistent interface for a set of interfaces in a subsystem that defines a high-level interface that makes this subsystem 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 three classes of Modulea, Moduleb, Modulec). 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 Code

Classes in the Subsystem role:

1. Public class Modulea {
2. //Schematic method
3. public void TestA () {
4. System.out.println ("Call the Testa method in Modulea");
5. }
6. }

 

1. Public class Moduleb {
2. //Schematic method
3. public void Testb () {
4. System.out.println ("Call the Testb method in Moduleb");
5. }
6. }

1. Public class Modulec {
2. //Schematic method
3. public void Testc () {
4. System.out.println ("Call the Testc method in Modulec");
5. }
6. }

Façade role class:

2. Public class Facade {
4. //Schematic method to meet the functions required by the client
6. public Void Test () {
8. Modulea a = new Modulea ();
10. A.testa ();
12. Moduleb B = new Moduleb ();
14. B.testb ();
16. Modulec C = new Modulec ();
18. C.TESTC ();
20. }
22. }

Client Role classes:

2. Public class Client {
6. public static void Main (string[] args) {
10. Facade facade = new facade ();
12. Facade.test ();
14. }
18. }

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.

2. Public class Module {
4. /** 
6. * Methods for external use of subsystems
8. */
10. public void A1 () {};
14. /** 
16. * methods used when calling each other in the subsystem internal modules
18. */
20. private void A2 () {};
22. private void A3 () {};
24. }

2. Public class Moduleb {
4. /** 
6. * Methods for external use of subsystems
8. */
10. public void B1 () {};
14. /** 
16. * methods used when calling each other in the subsystem internal modules
18. */
20. private void B2 () {};
22. private void B3 () {};
24. }

2. Public class Modulec {
4. /** 
6. * Methods for external use of subsystems
8. */
10. public void C1 () {};
14. /** 
16. * methods used when calling each other in the subsystem internal modules
18. */
20. private void C2 () {};
22. private void C3 () {};
24. }

2. Public class Modulefacade {
6. Modulea a = new Modulea ();
8. Moduleb B = new Moduleb ();
10. Modulec C = new Modulec ();
12. /** 
14. * These are the methods that the A, B, and C modules provide outside the subsystem
16. */
18. public void A1 () {
20. A.A1 ();
22. }
24. public void B1 () {
26. B.B1 ();
28. }
30. public void C1 () {
32. C.c1 ();
34. }
36. }

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.

Façade mode