In-depth design pattern--appearance mode (facade pattern)

Mode motive

After the appearance role is introduced, the user only needs to interact directly with the appearance role, and the complex relationship between the user and the subsystem is implemented by the appearance role, thus reducing the coupling of the system.

Pattern definition
Appearance mode (facade pattern): External communication with a subsystem must be done through a unified appearance object, providing a consistent interface for a set of interfaces in a subsystem, and a façade pattern that defines a high-level interface that makes this subsystem easier to use. Appearance mode, also known as façade mode, is an object-structured pattern.
Facade Pattern:provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Frequency of Use:high
UML diagram

Pattern structure
The appearance pattern contains the following roles:
Facade: Appearance role
SubSystem: Subsystem Role

Pattern Analysis
According to the principle of single responsibility, dividing a system into several subsystems in software is helpful to reduce the complexity of the whole system, and a common design goal is to minimize the communication and interdependence among subsystems, and one of the ways to achieve this is to introduce a visual object. It provides a simple and single entry for subsystem access.
The appearance mode is also the embodiment of "Dimitri Law" , by introducing a new appearance class can reduce the complexity of the original system, and reduce the coupling degree between the customer class and the Subsystem class.
The appearance mode requires that the external and internal communication of a subsystem be done through a unified appearance object, which separates the client from the internal complexity of the subsystem, making the client only needs to deal with the appearance object, without having to deal with many objects inside the subsystem.
The purpose of the appearance mode is to reduce the complexity of the system.
The appearance mode greatly improves the convenience of the client, so that the client does not care about the work details of the subsystem, and can invoke the related functions through the appearance role.

Pattern Instances and parsing
Investment Fund Code
System structure

SubSystem: Subsystem Role

Stock1.cs

 using   System;  namespace   facadepattern{  Stock1 { public  void   Sell () {Console.WriteLine (   stock 1 sell   " );  public  void   Buy () {Console.WriteLine (   shares        Ticket 1 is sold in   

stock2.cs

 using   System;  namespace   facadepattern{  Stock2 { public  void   Sell () {Console.WriteLine (   stock 2 sell   " );  public  void   Buy () {Console.WriteLine (   shares        Ticket 2 is sold in   

stock3.cs

 using   System;  namespace   facadepattern{  Stock3 { public  void   Sell () {Console.WriteLine (   stock 3 sell   " );  public  void   Buy () {Console.WriteLine (   shares        Ticket 3 is sold in   

Facade: Appearance role Fund.cs

namespacefacadepattern{classFund {Stock1 gu1;        Stock2 gu2;        Stock3 GU3;  PublicFund () {gu1=NewStock1 (); GU2=NewStock2 (); GU3=NewStock3 (); }         Public voidBuyfund () {gu1.            Buy (); Gu2.            Buy (); Gu3.        Buy (); }         Public voidSellfund () {gu1.            Sell (); Gu2.            Sell (); Gu3.        Sell (); }    }}

Client: Customer Class

 using   System;  namespace   facadepattern{  program { static  void  Main (string  [] args) {Fund Fund  = new   Fund (); Fund.            Buyfund (); Fund.            Sellfund ();        Console.read (); }    }}

Model Pros and cons
Advantages of the Appearance mode
? masking subsystem components to customers reduces the number of objects processed by the customer and makes the subsystem easier to use. By introducing the appearance pattern, the customer code becomes very simple, with very few objects associated with it.
? The loosely coupled relationship between the subsystem and the customer is realized, which makes the component changes of the subsystem not affect the customer class that calls it, only the appearance class needs to be adjusted.
? Reduces compilation dependencies in large software systems and simplifies the porting of systems between different platforms, since compiling a subsystem generally does not require compiling all of the other subsystems. The modification of one subsystem has no effect on other subsystems, and the internal changes of the subsystem do not affect the Appearance object.
? Just provides a unified portal to the access subsystem and does not affect the user's direct use of the subsystem class.

Disadvantages of Appearance mode
? It is not a good way to limit the use of subsystem classes for customers, and if too many restrictions on the client Access subsystem classes reduce variability and flexibility.
Without introducing an abstract appearance class, adding a new subsystem might require modifying the source code of the skin class or client, violating the "open and closed principle".

Mode applicable environment
You can use the Appearance mode in the following situations:
? You can use appearance mode when you want to provide a simple interface for a complex subsystem. The interface can meet the needs of most users, and users can access the subsystem directly over the appearance class.
There is a large dependency between the client program and multiple subsystems. Introducing the appearance class to decouple the subsystem from the customer and other subsystems can improve the independence and portability of the subsystem.
? In a hierarchical structure, you can use the appearance pattern to define the entry for each layer in the system, and the layers are not directly related to the layers, but the contact is established through the appearance class to reduce the coupling between the layers.

In-depth design pattern--appearance mode (facade pattern)