GOF Intent: To provide a consistent interface for a set of interfaces in a subsystem, this pattern defines a high-level interface that makes this subsystem easier to use
Role:
(1) Facade (facade role): its methods can be called on the client side, and the functions and responsibilities of the relevant (one or more) subsystems can be known in the facade role; The incoming request is delegated to the corresponding subsystem and passed to the corresponding subsystem object for processing.
(2) SubSystem (subsystem role): There can be one or more subsystem roles in the software system. Each subsystem can be not a separate class, but a collection of classes, which implements the functions of the subsystems; each Subsystems can be called directly by the client, or by the appearance role, which handles requests from the appearance class; the subsystem does not know the existence of the appearance, for the subsystem, the appearance role is just another client .
Implementation: slightly
scenes to be used:
1) Provide a simple interface to a complex subsystem.
2) In a hierarchical structure, the appearance mode can be used to define the entry of each layer in the system.
3) Subsystems need independence.
advantage:
1) Facade mode shields the subsystem components from the client, thereby simplifying the interface, reducing the number of objects handled by the client and making the use of the subsystem easier.
2) The appearance pattern realizes the loosely coupled relationship between the subsystem and the client, while the functional components inside the subsystem are tightly coupled. Loose coupling allows component changes of a subsystem to not affect its clients.
shortcoming:
Adding new subsystems may require modification of facade classes or clients, violating the "open-closed principle".