C + + design pattern appearance pattern _c language

Objective

In the actual development, the face of a large system, will always be a large system into several subsystems, such as subsystems completed, and then call the corresponding subsystems to complete the corresponding overall function, which is conducive to reducing the complexity of the system; When the final implementation of a specific function, We will combine the corresponding subsystems, but it is difficult to combine the subsystems so much, the relationship is so complex, the combination form a complete system.

When we compile C + + code using Visual Studio, you just select build in the menu, and then Visual Studio starts a bunch of compilation work; You should know that because of your simple build action, the compiler will parse it in the background, Generate intermediate code, generating assembly code, linking to executable programs or libraries, and so on, and all this, as we are just developing the program, without having to understand what the compiler is doing, the compiler hides a series of complex operations behind us and only provides a build button, the Build button, You can do all the work; When you click the Build button, the builds are behind the scenes, distributing the tasks to different subsystems to complete, and the final subsystem collaborating to complete the entire compilation task. And this hides some complex operations, providing only a higher level of the unified interface, which I summarized today in the appearance pattern.

What is the appearance pattern?

Appearance mode, many people also call it the façade mode. In Gof's design pattern: The basics of reusable object-oriented software, the appearance pattern is said to provide a consistent interface to a set of interfaces in a subsystem, which defines a high-level interface that makes the subsystem easier to use. A thin understanding of this sentence; a set of interfaces in a subsystem, like the syntax analysis shown above, generates intermediate code, generates assembly code, links to executable programs or libraries; A high-level interface defined by the appearance pattern, like the build button mentioned above, To make the compiler easier to use, for this, programmers who turn Windows C++/C from Linux c++/c are most experienced. Visual Studio provides a powerful feature that requires only a build button to perform a built action without having to write makefile files and then execute some commands for compilation.

UML Class Diagram

Facade: Know which subsystem classes are responsible for processing requests and delegate the client's request to the appropriate subsystem object;

SUBSYSTEM: implements subsystem specific functions, handles tasks assigned by the façade object, but subsystem does not have any relevant information about the façade, that is, there is no pointer to the façade.

The client communicates with the subsystem by sending a request to the façade, rather than directly dealing with the subsystem, and the façade forwards the messages to the appropriate subsystem object. Although the object in the subsystem is doing the actual work, the façade pattern itself must transform its interface into a subsystem interface, is there a sense of adapter mode here? This is the sense of learning structural design patterns, and the feeling is very similar, but careful to study, you will find their own usefulness.

Code implementation

The code implemented here is the example of the compiler I mentioned above.

Copy Code code as follows:

/*
* * Filename:facadepatterndemo
* * author:jelly Young
* * DATE:2014/1/2
* * Description:more information, http://www.jb51.net
*/

#include <iostream>
using namespace Std;

Syntax Analysis subsystem
Class Csyntaxparser
{
Public
void Syntaxparser ()
{
cout<< "Syntax Parser" <<endl;
}
};

Generate Intermediate Code Subsystem
Class Cgenmidcode
{
Public
void Genmidcode ()
{
cout<< "Generate Middle Code" <<endl;
}
};

Generating assembly Code Subsystem
Class Cgenassemblycode
{
Public
void Genassemblycode ()
{
cout<< "Generate assembly Code" <<endl;
}
};

Chain delivered into an executable application or library subsystem
Class Clinksystem
{
Public
void Linksystem ()
{
cout<< "Link System" <<endl;
}
};

Class Façade
{
Public
void Compile ()
{
Csyntaxparser Syntaxparser;
Cgenmidcode Genmidcode;
Cgenassemblycode Genassemblycode;
Clinksystem Linksystem;
Syntaxparser.syntaxparser ();
Genmidcode.genmidcode ();
Genassemblycode.genassemblycode ();
Linksystem.linksystem ();
}
};

Client
int main ()
{
Façade façade;
Facade.compile ();
}

The code above is very simple. We can imagine that without the use of the appearance pattern, the client would have to write a bunch of code in the same way as the compile if it were to compile the same action; Yes, you would say, write it. However, sometimes, the client is not very familiar with the relationship between subsystems, like, first to parse, then generate intermediate code, and then generate assembly language, the last link. What if the client doesn't know about the timing? Therefore, the appearance of the model so that all the complicated things, the use of the easy to change.

Advantages

1. It masks the subsystem components for customers, thus reducing the number of objects processed by clients and making the subsystem more convenient to use;

2. It realizes the loose coupling relationship between the subsystem and the customer, and the function components inside the subsystem are often tightly coupled; the loosely coupled system makes the components of the subsystem change without affecting its customers. The skin pattern helps to establish a hierarchical system and also helps to tier dependencies between objects. The appearance pattern eliminates complex cyclic dependencies. This is especially important when client programs and subsystems are implemented separately.

Use occasion

1. When you want to provide a simple interface for a complex subsystem. Subsystems tend to become more complex as they evolve. Most patterns will produce more and smaller classes when used. This makes subsystems more reusable and easier to customize subsystems, but it also brings some usability difficulties for users who do not need a custom subsystem. The skin pattern provides a simple default view, which is sufficient for most users, and those who need more customization can cross the façade layer;

2. There is a large dependency between the client program and the implementation part of the abstract class. The introduction of the façade separates the subsystem from the client and other subsystems, which can improve the independence and portability of the subsystem.

3. When you need to build a hierarchical subsystem, use the skin pattern to define the entry points for each layer in the subsystem. If subsystems are interdependent, we can simplify their dependencies by allowing them to communicate only through a façade.

Summarize

The appearance mode is simple and easy to use, so that the customer can make the subsystem easier; in reading someone else's article, the following summary is very good, I also learn from:

1. In the early stage of design, should be aware of the separation of different layers, such as the commonly used three-tier architecture, is to consider the data access layer, and the business logic layer between the presentation layer, to create a façade, so that the complex subsystem to provide a simple interface to reduce coupling;

2. In the development phase, subsystems tend to become more and more complex because of continuous refactoring, and an increase in façade facades can provide a simple interface to reduce dependency between them;

3. During the maintenance phase, perhaps this system is already very difficult to maintain and expand, and you can develop a visual class for the new system to provide a relatively clear and simple interface for designing rough or highly complex legacy code, allowing the new system to interact with the façade objects, and the façade to interact with the legacy code for all the complex work.

Generally speaking, we provide a façade layer for subsystem access, and this façade entry requires only one; that is, when using a façade, we can use a single case pattern to implement the façade pattern. For the appearance of the model to complete the summary, there must be some places missing, please correct me. I firmly believe that sharing makes us more progress.