Design Pattern-Facade Pattern (facade)

To understand the design pattern correctly, we must first clarify what problems it proposes to solve.

Design Mode Study Notes

-- Shulin

Reprinted please indicate the source: http://blog.csdn.net/zhshulin

1. Concepts

The facade mode is the object structure mode. External communication with a sub-system must be performed through a unified facade object. The facade mode provides a high-level interface to make subsystems easier to use.

2. Problems

Provides a high-level interface for subsystems to make them easy to use.

Applicability:

1) when you want to provide a simple interface for a complex subsystem. Subsystems tend to become more and more complex as they evolve. In most modes, More and smaller classes are generated. This makes subsystems more reusable and easier to customize, but it also brings some difficulties for users who do not need to customize subsystems. Facade can provide a simple default view, which is sufficient for most users, and users who need more customization can bypass the facade layer. (To put it simply, the facade is to provide some basic services to meet the needs of most users, and those with special requirements can bypass the facade and directly interact with the system)

2) there is a large dependency between the implementation part of the client program and the abstract class. Introducing facade to separate this subsystem from customers and other subsystems can improve the independence and portability of the subsystem.

3) when you need to build a layered sub-system, use the facade mode to define the entry points for each layer of the sub-system. If subsystems are mutually dependent, you can make them communicate only through facade, thus simplifying the dependency between them.

3. role composition

The facade mode is the object structure mode. The facade mode does not have a general class diagram description, which demonstrates a schematic object diagram of the facade mode:

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 facade role. The subsystem does not know the existence of the facade. For the subsystem, the facade is just another client.

4. Examples
4.1 example description

Modern software systems are complex. A common method for designers to process complex systems is to divide them into several smaller subsystems.

Example of a hospital: If a hospital is used as a sub-system, the system can be divided into registration, outpatient service, price assignment, testing, billing, and drug taking according to the Department's functions. It is not easy for a patient to deal with these departments, just as the client of a sub-system deals with various categories of a sub-system.

First, the patient must register first and then go to the clinic. If the doctor asks for a test, the patient must first make a price and then pay the fee before going to the test department for a test. After the test, return to the clinic.

To solve this problem, the hospital can set up a receptionist's location. The receptionist is responsible for registration, price calculation, payment, and drug withdrawal. This receptionist is the embodiment of the facade model. The patient only contacts the receptionist, who deals with various departments.

4.2 class diagram

4.3 Source Code

Specific service categories:

/*** Register ** @ author zsl */public class register {public void register () {system. Out. println ("to register! ");}}

/*** Outpatient * @ author zsl */public class treatment {public void treat () {system. Out. println ("cure! ");}}

/*** Payment * @ author zsl */public class payment {public void pay () {system. Out. println ("payment! ");}}

/*** Take medicine ** @ author zsl */public class drugstore {public void getdrug () {system. Out. println ("take medicine! ");}}

Facade ):

/*** Portal class, equivalent to hospital reception * @ author zsl */public class facade {private register; private treatment; private payment; private drugstore; public facade () {register = new register (); Treatment = new treatment (); payment = new payment (); drugstore = new drugstore ();} // reception registration public void register () {register. register ();} // the reception desk carries the patient for treatment. This is a bit inappropriate. After all, the patient needs to deal directly with the doctor. To understand this, it is good to understand public void treat () {treatment. treat ();} // public void pay () {payment. pay ();} // public void getdrug () {drugstore. getdrug ();}}

Test class:

/*** Client * @ author zsl */public class client {public static void main (string [] ARGs) {facade = new facade (); facade. register (); facade. treat (); facade. pay (); facade. getdrug ();}}

One disadvantage of this example is that the outpatient service should allow the client to directly deal with the outpatient service, and other services can be conducted through the reception center (facade) to facilitate patient visits. But it does not affect the design idea of the facade model, but is easier to understand. The facade mode is to extract the basic functions of the subsystem to meet the needs of most users. If you have special requirements, you can directly interact with specific classes.

5. Advantages

? Loose coupling

The client is decoupled from the subsystem, making it easier to expand and maintain modules within the subsystem.

? Easy to use

The client only needs to interact with the door class.

? Better access levels

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 facade, which facilitates the use of the client and hides the internal details.

6. Disadvantages

Does not comply with the principle of open and closed. The so-called open and closed principle is the most basic principle in software engineering: open to expansion and close to modification. In other words, your system can provide new functional modules without any modifications.