I understand the design pattern (C ++ implementation)-Facade Pattern)

Overview

Think about the four-wheel drive that we played when we were a child. The structure is very complicated, including the motor, steering gear, and battery pack. But we can control it very easily, as long as we turn on the Battery switch, he can run it. In fact, we don't need to know how it works, as long as we know that the switch can work. This switch actually gives us a friendly component, so that we can easily control it.

The appearance mode actually defines a high-level interface, which provides a consistent interface for a group of interfaces in the subsystem, making this subsystem easier to use.

Class Diagram and example

In this object diagram, two roles are displayed:

Facade role: The client can call this role method. This role is aware of the functions and responsibilities of one or more subsystems. Under normal circumstances, this role delegates all requests sent from the client to the corresponding subsystem.

Subsystem role: You can have one or more subsystems at the same time. Every subsystem is not a separate class, but a collection of classes. Each subsystem can be called directly by the client or by the appearance role. The subsystem does not know the appearance. For the subsystem, the appearance is just another client.

# Include <iostream> using namespace STD; Class Identifier {public: void scan () {cout <"lexical analysis" <Endl ;}}; class parser {public: void parse () {cout <"syntax analysis" <Endl ;}}; class genmidcode {public: void gencode () {cout <"generate intermediate code" <Endl ;}; class genmachinecode {public: void gencode () {cout <"generate machine code" <Endl ;}}; // high-level interface fecadeclass compiler {public: void run () {partition; parser; genmidcode; genmachinecode genmaccode; signature. scan (); parser. parse (); genmidcode. gencode (); genmaccode. gencode () ;}}; // clientint main () {compiler; compiler. run (); Return 0 ;}

Key Points

1. The facade mode shields sub-system components from the customer, thus reducing the number of objects processed by the customer and making the sub-system more convenient to use.

2. The facade mode implements loose coupling between subsystems and customers, while functional components inside the subsystems are usually tightly coupled. The loose coupling makes the Component Changes of the subsystem do not affect its customers.

3. If the application needs it, it does not limit the use of sub-system classes. Therefore, you can choose between ease of use and versatility of the system.

4. In appearance mode, only one appearance class is required, and the appearance class has only one instance. In other words, it is a singleton class. Of course, this does not mean that there is only one appearance class in the entire system, but only one appearance class for each subsystem. In other words, if a system has several subsystems, each subsystem has an appearance class, and the entire system can have several appearance classes.

5. The appearance mode is intended to provide a centralized and simplified communication channel for the subsystem, rather than adding new behaviors to the subsystem.

6. The appearance mode focuses on simplified interfaces. More often, it looks at the entire system from the architectural hierarchy rather than the hierarchy of a single class.

Applicability and advantages and disadvantages Applicability

1. provides a simple interface for a complex subsystem.

2. Improve the independence of subsystems.

3. In a hierarchical structure, you can use the facade mode to define the entries for each layer of the system.

Advantages

1. Loose coupling
The appearance mode loose the coupling relationship between the client and subsystem, making it easier to expand and maintain modules within the subsystem. Point 2.

2. ease of use
The appearance mode makes the subsystem easier to use. The client no longer needs to understand the internal implementation of the subsystem, nor needs to interact with the internal modules of many subsystems. It only needs to interact with the appearance, the appearance class provides an all-in-one service for external clients to use subsystems.

3. Better access levels
The rational use of Facade can help us better divide access layers. Some methods are external to the system, and some methods are used inside the system. The functions that need to be exposed to the external are concentrated in the appearance, which is convenient for the client to use and hides the internal details.

Disadvantages

Too many or unreasonable facade may also be confusing. Is it better to call facade or directly call the module.

Lcl_data was originally created in csdn. Net [http://blog.csdn.net/lcl_data/article/details/8842579]