Java Common design Pattern 12: The common design pattern of the appearance mode (structural mode)

1. Java view mode (facade pattern)

(1) Overview:

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.

appearance mode (facade): 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.

(2) the structure of the appearance mode:

The appearance pattern does not have a generalized class diagram description, and the best description method is actually illustrated with an example.

Because the structure diagram of the appearance pattern is too abstract, make it a little bit 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 :

appearance (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.

2. Code implementation:

(1) Classes in the subsystem role :

1  Public class Modulea {  2     // schematic method   3      public  void  TestA () {  4         System.out.println ("Calls to TestA method in Modulea");   5     }  6

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

1  Public class Modulec {  2     // schematic method   3      public  void  TESTC () {  4         System.out.println ("Calls to Testc method in Modulec");   5     }  6

(2) appearance role class:

1 classFacade {2     PrivateModulea Modulea =NewModulea ();3     PrivateModuleb Moduleb =NewModuleb ();4     PrivateModulec Modulec =NewModulec ();5 6     7 8      Public voidOp1 () {9System.out.println ("Facade OP1 ()");Ten Modulea.testa (); One     } A  -      -      Public voidop2 () { theSystem.out.println ("Facade op2 ()"); - Moduleb.testb (); -     } -  +      -  +      Public voidop3 () { ASystem.out.println ("Facade op3 ()"); at MODULEC.TESTC (); -     } -   -  -      Public voidMethod () { -System.out.println ("Facade Method ()"); in modulec.op3 (); - moduleb.op2 (); to Modulea.op1 (); +     } -  the}

(3) client role class:

1  Public classClient {2   3      Public Static voidMain (string[] args) {4Facade facade =Newfacade ();5 facade.        Method (); 6 Facade.op1 ();7     8     }  9   Ten}     

Operation Result:

1 facade Method () 2 Method 3 3 Method 2 4 Method 1 5 facade OP1 () 6 Method 1

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.

3. Main points of the appearance mode:

(1) The Appearance mode provides a simple interface for complex subsystems and does not add new functions and behaviors for subsystems.

(2) The appearance mode realizes the loosely coupling relationship between the subsystem and the customer.

(3) The appearance mode does not encapsulate the class of the subsystem, but simply provides a simple interface. If required by the application, it does not restrict the use of subsystem classes by customers. It is therefore possible to choose between ease of use and versatility.

(4) The appearance mode is focused on simplifying the interface, it is more time to see the whole system from the level of the architecture, rather than the level of a single class.

Java Common design Pattern 12: The common design pattern of the appearance mode (structural mode)