Extract the design pattern from the appearance pattern (Facade)

The 23 GOF design modes are generally divided into three categories: Creation Mode, structure mode, and behavior mode.

The Creation Mode abstracts the instantiation process, which helps a system to create, combine, and express its objects independently. A class creation mode uses inheritance to change the class to be instantiated, while an object Creation Mode delegates the Instantiation to another object. The creation mode has two main themes. First, they all encapsulate information about the specific classes used by the system. Second, they hide how instances of these classes are created and put together. All objects in the system know interfaces defined by abstract classes. Therefore, the Creation Mode gives great flexibility in what is created, who creates it, how it is created, and when it is created. They allow you to configure a system with "product" objects with very different structures and functions. The configuration can be static (specified during compilation) or dynamic (at runtime ).

The schema involves how to combine classes and objects to obtain a larger structure. The structure class mode uses an Inheritance Mechanism to combine interfaces or implementations. The structured object mode not combines interfaces and implementations, but describes how to combine some objects to implement new functions. Because the object composite relationship can be changed at runtime, the object composite method has more flexibility, and this mechanism is impossible to achieve with static class composite.

The behavior pattern involves the assignment of duties between algorithms and objects. The behavior pattern not only describes the object or class pattern, but also describes the communication pattern between them. These modes depict complex control flows that are difficult to trace during runtime. They shift users' attention from the control flow to the contact information between objects. The behavior class mode uses the Inheritance Mechanism to distribute actions among classes. Behavior object mode uses Object combination instead of inheritance. Some behavior object modes describe how peer-to-peer objects collaborate to complete tasks that cannot be completed independently by any object.

The creation mode includes: 1. FactoryMethod (Factory method mode); 2. Abstract Factory (Abstract Factory mode); 3. Singleton (Singleton mode); 4. Builder mode and Builder mode ); 5. Prototype (Prototype ).

Structural modes include: 6. Bridge (Bridge Mode); 7. Adapter (Adapter mode); 8. Decorator (decoration mode); 9. Composite (combination mode ); 10. Flyweight (metadata mode); 11. Facade (appearance mode); 12. Proxy mode ).

Behavior patterns include: 13. TemplateMethod (template method mode); 14. Strategy (Policy mode); 15. State (State mode); 16. Observer (Observer mode ); 17. Memento (memorandum mode); 18. Mediator (intermediary mode); 19. Command (Command mode); 20. Visitor (Visitor mode ); 21. Chain of Responsibility (responsible Chain mode); 22. Iterator (Iterator mode); 23. Interpreter (Interpreter mode ).

Factory Method: Defines an interface for creating objects, so that the subclass determines which class to instantiate. Factory Method delays the instantiation of a class to its subclass.

Abstract Factory: Provides an interface for creating a series of related or mutually dependent objects without specifying their specific classes.

Singleton: Ensure that a class has only one instance and provides a global access point to it.

Builder: Separates the construction of a complex object from its representation, so that different representations can be created during the same construction process.

Prototype: Use a prototype instance to specify the type of the object to be created, and copy the prototype to create a new object.

Bridge: Separates abstract parts from their implementations so that they can all change independently.

Adapter: Converts an interface of a class to another interface that the customer wants. The Adapter mode allows the classes that cannot work together due to incompatibility of interfaces to work together.

Decorator: Dynamically add some additional responsibilities to an object. In terms of extended functions, the Decorator mode is more flexible than the subclass generation method.

Composite: Combine objects into a tree structure to represent the "part-whole" hierarchy. Composite makes the customer's use of a single object and Composite object consistent.

Flyweight: Use the sharing technology to effectively support a large number of fine-grained objects.

Facade: Provides a consistent interface for a group of interfaces in the subsystem. The Facade mode defines a high-level interface, which makes the subsystem easier to use.

Proxy: Provides a proxy for other objects to control access to this object.

Template Method: Defines the skeleton of an algorithm in an operation, and delays some steps to the subclass. The Template Method allows the subclass to redefine certain steps of an algorithm without changing the structure of an algorithm.

Strategy: Define a series of algorithms, encapsulate them one by one, and make them replaceable. This mode makes the algorithm changes independent of the customers who use it.

State: Allows an object to change its behavior when its internal state changes. The object seems to have modified its class.

Observer: Defines a one-to-many dependency between objects, so that when the status of an object changes, all objects dependent on it will be notified and automatically refreshed.

Memento: Capture the internal state of an object without compromising encapsulation, and save the state outside the object. In this way, the object can be restored to the Saved state.

Mediator: Encapsulate a series of object interactions with an intermediary object. The intermediary makes the objects do not need to be explicitly referenced to each other, so that the coupling is loose and the interaction between them can be changed independently.

Command: Encapsulate a request as an object so that you can parameterize the customer with different requests, queue requests or record request logs, and support cancelable operations.

Visitor: Indicates an operation that acts on each element in an object structure. It allows you to define new operations that act on these elements without changing the classes of each element.

Chain of Responsibility: To remove the coupling between the request sender and receiver, multiple objects have the opportunity to process the request. Connect these objects into a chain and pass the request along the chain until an object processes it.

Iterator: Provides a method to access each element in an aggregate object sequentially without exposing the internal representation of the object.

Interpreter: For a given language, define a representation of its syntax and define an interpreter that uses this representation to interpret sentences in the language.

Facade :( 1) intent: provide a consistent interface for a group of interfaces in the subsystem. The Facade mode defines a high-level interface, which makes the subsystem easier to use.

(2) motivation: dividing a system into several subsystems helps reduce the complexity of the system. A common design goal is to minimize the communication and dependency between subsystems. One way to achieve this goal is to introduce a facade object, which provides a single and simple interface for the more common facilities in the subsystem.

(3) Applicability: Apply the Facade mode in the following situations: A. 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. B. 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. C. 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.

(4) Advantages: A. It 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. B. It 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. The Facade mode helps you establish a hierarchical system and layer dependencies between objects. The Facade mode eliminates complex circular dependencies. This is especially important when the customer program and subsystem are implemented separately. It is critical to reduce compilation dependencies in large software systems. When the sub-system class changes, we hope to minimize the re-compilation effort to save time. Using Facade can reduce compilation dependencies and limit minor changes in important systems. The Facade mode also simplifies the porting process between different platforms, because compiling a sub-system generally does not need to compile all other subsystems. C. If the application needs it, it does not limit the use of sub-system classes. Therefore, you can choose between the ease of use and versatility of the system.

(5) Considerations: A. Reduce the Coupling Degree between the customer and sub-systems: use abstract classes to implement Facade, and its specific sub-classes correspond to different sub-systems, this can further reduce the coupling between customers and subsystems. In this way, the customer can communicate with the subsystem through the abstract Facade class interface. This abstract coupling relationship makes the customer do not know which implementation of the subsystem is used. In addition to the subclass generation method, another method is to configure the Facade object with different subsystem objects. To customize a facade, you only need to replace its subsystem objects (one or more. B. Public and private sub-system classes: a sub-system is similar to a class in that they all have interfaces and they all encapsulate something-the class encapsulates states and operations, the subsystem encapsulates some classes. It is helpful to consider the Public and Private interfaces of a class. We can also consider the Public and Private interfaces of the subsystem. The public interface of the subsystem contains all the classes accessible to the client program. The private interface is only used to expand the subsystem. Of course, the Facade class is part of a public interface, but it is not the only part. The other part of the subsystem is usually public. Private sub-system classes are useful, but few object-oriented programming languages support this.

(6) related mode: The AbstractFactory mode can be used with the Facade mode to provide an interface, which can be used to create subsystem objects in a seed system independent way. Abstract Factory can also hide platform-related classes in place of the Facade mode. Similar to the Facade mode, the Mediator mode abstracts some existing class functions. However, Mediator aims to abstract any communication between colleagues, and generally does not belong to any single object. A Mediator colleague knows the intermediary and communicates with it, instead of directly communicating with other similar objects. Relatively speaking, the Facade mode only abstracts the interfaces of subsystem objects to make them easier to use. It does not define new functions, nor does the subsystem know the existence of the Facade. Generally, only one Facade object is required, so the Facade object is usually in the Singleton mode.

Provides a consistent interface for a set of sub-system interfaces. Makes it easier for users to use.

The Facade mode provides a unified interface at the high-level level, decoupling the system. In the design mode, there is another mode in which Mediator is similar to Facade. However, Mediator mainly aims to decouple access between objects (protocols for communication ).

Sample Code 1:

# Include
 
  
# Include
  
   
Using namespace std; class SubSysOne {public: void MethodOne () {cout <"method 1" <
   
    
MethodOne (); sub2-> MethodTwo (); sub3-> MethodThree () ;}; // client int main () {Facade * test = new Facade (); test-> FacadeMethod ();/* result method 1 method 2 method 3 */return 0 ;}
   
  
 

Sample Code 2:

Facade. h:

#ifndef _FACADE_H_#define _FACADE_H_class Subsystem1{public:Subsystem1();~Subsystem1();void Operation();protected:private:};class Subsystem2{public:Subsystem2();~Subsystem2();void Operation();protected:private:};class Facade{public:Facade();~Facade();void OperationWrapper();protected:private:Subsystem1* _subs1;Subsystem2* _subs2;};#endif //~_FACADE_H_

Facade. cpp:

#include "Facade.h"#include 
 
  using namespace std;Subsystem1::Subsystem1(){}Subsystem1::~Subsystem1(){}void Subsystem1::Operation(){cout<<"Subsystem1 operation ..."<
  
   _subs1 = new Subsystem1();this->_subs2 = new Subsystem2();}Facade::~Facade(){delete _subs1;delete _subs2;}void Facade::OperationWrapper(){this->_subs1->Operation();this->_subs2->Operation();}
  
 

Main. cpp:

#include "Facade.h"#include 
 
  using namespace std;int main(){Facade* f = new Facade();f->OperationWrapper();/*resultSubsystem1 operation ...Subsystem2 operation ...*/return 0;}
 

Appearance mode structure:

References:

1. Big talk Design Model C ++

2. Design Patterns-Analysis of GoF23 Design Patterns

3. Design Patterns-Basis for reusable Object-Oriented Software