Simple appearance mode (1)

Appearance mode is a frequently used structural design mode. It introduces an appearance role to simplify the interaction between the client and the subsystem, and provides a unified entrance for complicated subsystem calls, this reduces the coupling between subsystems and clients and facilitates client calls.

 

1. Appearance mode Overview

I don't know if you have compared the differences between making tea on your own and drinking tea on your own. If you are making tea on your own, you need to prepare tea, tea set and boiling water on your own, as shown in 1 (, the simplest way is to tell the teahouse attendant what kind of tea they want, whether it is Tieguanyin, Biluochun or Xihu Longjing? Because there are waiters in the tea house, customers do not need to directly interact with tea, tea set, and boiling water. The whole tea process is completed by the waiters. The customer only needs to interact with the waiters. The whole process is very simple and easy to use, 1 (B.

Figure 1 two tea drinking Modes

In software development, sometimes in order to complete a complex function, a customer class needs to interact with multiple business classes, and these business classes that need to interact often appear as a whole, because there are many classes involved, the use of time codes is more complex. In this case, a role similar to a waiter is required for interaction with multiple business classes, the customer class only needs to interact with the class. The appearance mode introduces a newFacade)The appearance class acts as a "waiter" in the software system. It provides a unified entrance for calling multiple business classes and simplifies interaction between classes. In appearance mode, business classes that require interaction are calledSubsystem (subsystem). If there is no appearance class, then each customer class needs to perform complex interaction with multiple subsystems, and the coupling degree of the system will be large, as shown in 2 (a). After the appearance class is introduced, the customer class only needs to interact directly with the appearance class. The original complex reference relationship between the customer class and the subsystem is implemented by the appearance class, thus reducing the Coupling Degree of the system, as shown in 2 (B.

Figure 2 appearance Mode

In appearance mode, the external communication between a sub-system and its internal communication is performed through a unified appearance class, which separates the internal complexity of the customer class from that of the sub-system, so that the customer class only needs to deal with the appearance role, rather than dealing with many objects in the subsystem.

The appearance mode is defined as follows:

Appearance mode:Provides a unified portal for a group of interfaces in the subsystem. The appearance mode defines a high-level interface, which makes this subsystem easier to use. Facade Pattern:Provide a uniied interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

The appearance mode is also called the facade mode. It is an object structure mode. Appearance mode is a specific implementation of the Demeter rule. By introducing a new appearance role, the complexity of the original system can be reduced, and the coupling between the customer class and the subsystem can be reduced.

 

2. Structure and implementation of appearance mode 2.1

The appearance pattern does not have a general class graph description. It usually uses 2 (B) to represent the appearance pattern. The class diagram shown in Figure 3 can also be used as a structure diagram to describe the appearance mode:

Figure 3 structure of appearance Mode

As shown in figure 3, the appearance mode contains the following two roles:

(1) facade (appearance role ):The client can call its method to understand the functions and responsibilities of the relevant (one or more) sub-systems in the appearance role. Under normal circumstances, it delegates all requests sent from the client to the corresponding subsystem and transmits them to the corresponding subsystem object for processing.

(2) subsystem (subsystem role ):In a software system, one or more sub-system roles can be defined. Each sub-system can be a collection of classes rather than a separate class. It implements sub-system functions; each subsystem can be called directly by the client or by the appearance role, which processes requests sent from the appearance class. The subsystem does not know the appearance. For the subsystem, the appearance role is just another client.

 

2.2 mode implementation

The main purpose of the appearance mode is to reduce the complexity of the system. In an object-oriented software system, the more the relationship between classes, the better the system design, it means that the coupling between classes in the system is too large. Such a system lacks flexibility in maintenance and modification, because changes to one class will lead to changes to multiple classes, the introduction of the appearance mode greatly reduces the coupling between classes. After the appearance mode is introduced, it is very convenient to add or remove a new subsystem. The customer class does not need to be modified (or rarely modified ), you only need to add or remove a reference to the subsystem in the appearance class. From this point of view, the appearance mode does not conform to the principle of opening/closing to a certain extent. To add a new subsystem, you need to make certain modifications to the original system, although this modification does not work much.

The subsystem in appearance mode is a broad concept. It can be a class, a function module, an integral part of the system, or a complete system. The sub-system class is usually a business class that implements some specific and independent business functions. The typical code is as follows:

Class sub‑ema {public void methoda () {// business implementation code} class subsystemb {public void methodb () {// business implementation code} class sub‑emc {public void methodc () {// business implementation code }}

After the appearance class is introduced, the interaction with the Subsystem Service class is completed by the appearance class. The following code usually exists in the appearance class:

class Facade{    private SubSystemA obj1 = new SubSystemA();    private SubSystemB obj2 = new SubSystemB();    private SubSystemC obj3 = new SubSystemC();    public void Method()    {        obj1.MethodA();        obj2.MethodB();        obj3.MethodC();    }}

Because the reference to the subsystem object is maintained in the appearance class, the client can indirectly call the Business Method of the subsystem object through the appearance class, without directly interacting with the subsystem object. After the appearance class is introduced, the client code becomes very simple. The typical code is as follows:

class Program{    static void Main(string[] args)    {        Facade facade = new Facade();        facade.Method();    }}

[Author: Liu Wei http://blog.csdn.net/lovelion]