C # design Pattern-Appearance mode

First, the Appearance mode introduction:

The appearance mode provides a unified interface for a set of interfaces of a subsystem. The appearance defines a high-level interface that makes the subsystem easier to use. When using the appearance pattern, we created a unified class that wraps one or more complex classes in the subsystem, and the client can invoke the methods in the internal subsystem directly through the skin class, so that the appearance pattern avoids tight coupling between the client and the subsystem, and the appearance pattern can solve the layer structure separation, Reduces system coupling and provides interface capabilities for interacting with old and new systems. The appearance mode is also called "façade" mode.

Second, the emergence of the background:

In the software development process, the client program is often coupled with the internal subsystem of the complex system, which causes the client program to change with the subsystem, and in order to decouple the dependencies between the internal subsystem of the complex system and the client, there is the appearance pattern.

Third, design examples:

Take the production and sales of notebooks as an example, in the notebook industry chain system, notebook warehouse for a subsystem, notebook sales for another subsystem, when the buyer buy a certain amount, we need to confirm whether the inventory is satisfied before the completion of the transaction, inventory needs and buyer interaction prompt corresponding information.

Iv. Related code:

1. Create each subsystem class and define the respective methods:

    /// <summary>    ///Notebook Warehouse Subsystem/// </summary>     Public classNotebookfactory {/// <summary>        ///Verify that the inventory is meeting the requisition number/// </summary>        /// <param name= "Qty" ></param>        /// <returns></returns>         Public BOOLCheckstock (intqty) {            if(Qty > -)            {                return false; }            return true; }    }

    /// <summary>    ///Sales Notebook Subsystem/// </summary>     Public classSellingnotebook {/// <summary>        ///prompt Information After sales confirmation is insufficient/// </summary>        /// <param name= "Notename" ></param>        /// <returns></returns>         Public BOOLNotify (stringnotename) {Console.WriteLine ("{0} Insufficient inventory", Notename); return false; }    }

2, create the Appearance class, provide a unified interface:

    /// <summary>    ///Appearance class/// </summary>     Public classFacade {Privatenotebookfactory Production_note_book; PrivateSellingnotebook Selling_note_book;  Publicfacade () {Production_note_book=Newnotebookfactory (); Selling_note_book=NewSellingnotebook (); }         Public BOOLSource (intQtystringnotename) {            //Verify Inventory If inventory is sufficient to return true            if(Production_note_book. Checkstock (qty)) {return true; }            //Insufficient inventory alert message            returnSelling_note_book.        Notify (Notename); }    }

3. Call

         Public StaticFacade facade =Newfacade (); Static voidMain (string[] args) {            intDemand = -; stringNotename ="Lenovo Notebook"; if(facade. Source (demand, Notename)) {Console.WriteLine ("successfully sold {0} units {1}! ", demand, notename);        } console.readkey (); }    }

After using the appearance mode, the client only relies on the appearance class, thus decoupling the client from the subsystem's dependency, and if the subsystem changes, the client's code does not need to be changed at this time. the core of the implementation of the appearance pattern is to save the reference of each subsystem by the appearance class, and to wrap the multiple subsystem classes by a unified appearance class, but the client only needs to refer to the Appearance class, and then the method in each subsystem is called by the Appearance class . However, this implementation is very similar to the adapter pattern, but the appearance mode differs from the adapter pattern: The adapter pattern is to wrap an object in order to change its interface, and the appearance is to "wrap" a group of objects to simplify its interface. Their intentions are different, the adapter is to convert the interface to various interfaces, and the appearance mode is to provide a unified interface to simplify the interface .

V. Conditions of Use:

1. Provides a simple interface for a complex subsystem.
2. Provides the independence of the subsystem.
3. In a hierarchical structure, you can use the appearance pattern to define the entry for each layer in the system, such as a three-tier architecture.

Vi. Related roles:

façade (facade) Role : The method by which the client invokes this role. The role knows the functions and responsibilities of one or more subsystems that are related, and the role will be delegated the request from the client to the appropriate subsystem.

Subsystem (SUBSYSTEM) role : You can include 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 by a façade role. For subsystems, the façade is just another client, and the subsystem does not know the presence of the façade.

Vii. Summary:

Advantages:

1. The appearance mode shields the subsystem components from the customer, thus simplifying the interface, reducing the number of objects processed by the customer and making the subsystem easier to use.
2. The appearance pattern realizes the loosely coupling relationship between the subsystem and the customer, and the functional components inside the subsystem are tightly coupled. Loose coupling makes the component changes in the subsystem unaffected to its customers.

Disadvantages:

1. If you add a new subsystem, you may need to modify the source code of the skin class or client.

C # design Pattern-Appearance mode