Design Mode C ++ implementation (7) -- appearance mode and Combination Mode

the design patterns in the software field provide developers with an effective way to use expert design experience. In the design model, an important feature of the object-oriented programming language is used: encapsulation, inheritance, and polymorphism, understanding the essence of the design model is a long process that requires a lot of practical experience. I recently read a book on design patterns. I wrote a small example in C ++ for each pattern to help me better understand it. Refer to "big talk Design Patterns" and "design patterns: the basis for reusable object-oriented software" (DP. This article introduces the appearance of mode and combination mode .

The appearance mode should be a lot of patterns. Especially when a system is very complicated, what the system provides to the customer is a simple external interface, the complicated structure is encapsulated. Customers only need to use these simple interfaces to use the system, without having to focus on the complicated internal structure. Definition of DP: provides a consistent interface for a group of interfaces in the subsystem. The appearance mode defines a high-level interface, which makes the subsystem easier to use. For example, compile a compilerProgramFour steps are required: lexical analysis, syntax analysis, and intermediateCodeGeneration and machine code generation. Every step of compilation is complex. The appearance mode can be used for the compiler system. You can define a high-level interface, such as the Compiler class, which contains a class named runFunction. You only need to call this function to compile the program. You do not need to know the specific operations in the run function. The UML diagram is given below, taking the compiler as an example.

The Code is as follows:

Class detail {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 class compiler {public: void run () {partition parser; genmidcode; genmachinecode genmaccode; identifier. scan (); parser. parse (); genmidcode. gencode (); genmaccode. gencode ();}};
 

Customer usage:

 
Int main () {compiler; compiler. Run (); Return 0 ;}
 

This is the appearance mode. It has several features (from DP). (1) it shields sub-system components from customers, this reduces the number of objects processed by the customer and makes it easier for the subsystem to use. (2) It implements loose coupling between subsystems and customers, while functional components inside the subsystems are often tightly coupled. (3) If the application needs it, it does not limit the use of sub-system classes.

In combination with the above compiler example, we will further explain. For (1), the Compiler class shields sub-system components from the customer, and the customer can easily use the sub-system simply by processing the compiler objects. For (2), subsystem changes do not affect the use of the customer, reflecting the loose coupling between the subsystem and the customer. For (3), if you want to use the lexical analyzer, you only need to define the Class Object of the lexical analysis.

Appearance mode is useful when building large systems. Next we will introduce another mode, called the combination mode. It feels a bit like the appearance mode. When we implemented the appearance mode just now, the Compiler class contains objects of multiple classes, just like combining these classes. The combination mode is similar.

Definition in the DP book: Combine objects into a tree structure to represent a "part-whole" hierarchy. Combination makes the use of a single object and a composite object consistent. Note the two words "tree ". This tree structure can be seen everywhere in real life. For example, a group company has a parent company with many subsidiaries. Both the parent company and its subsidiaries have their respective financial departments, human resources departments, and sales departments. For the parent company, both the subsidiary company, the finance department and the human resources department are its departments. The Department topology of the entire company is a tree structure.

The following is a UML diagram of the combination mode. As you can see, the financedepartment and hrdepartment classes serve as leaf nodes, so no function is defined to be added. The concretecompany class can be used as an intermediate node, so you can add functions. So how to add it? This class defines a linked list for adding elements.

code implementation:

Class company {public: Company (string name) {m_name = Name;} virtual ~ Company () {} virtual void add (company * pcom) {} virtual void show (INT depth) {} protected: String m_name ;}; // company class concretecompany: public Company {public: concretecompany (string name): Company (name) {} virtual ~ Concretecompany () {} void add (company * pcom) {m_listcompany.push_back (pcom);} // located in the middle of the tree, you can add the subtree void show (INT depth) {for (INT I = 0; I <depth; I ++) cout <"-"; cout <m_name <Endl; List <company *> :: iterator iter = m_listcompany.begin (); For (; iter! = M_listcompany.end (); ITER ++) // display the lower node (* ITER)-> show (depth + 2);} private: List <company *> m_listcompany ;}; // specific department, Finance Department class financedepartment: Public Company {public: financedepartment (string name): Company (name) {} virtual ~ Financedepartment () {} virtual void show (INT depth) // you only need to display it. Add a function infinitely because it is already a leaf node {for (INT I = 0; I <depth; I ++) cout <"-"; cout <m_name <Endl ;}; // Specific Department, Human Resources Department class hrdepartment: Public Company {public: hrdepartment (string name): Company (name) {} virtual ~ Hrdepartment () {} virtual void show (INT depth) // you only need to display it. Add a function infinitely because it is already a leaf node {for (INT I = 0; I <depth; I ++) cout <"-"; cout <m_name <Endl ;}};

Customer usage:

 
Int main () {company * root = new concretecompany (""); company * leaf1 = new financedepartment ("Finance Department "); company * leaf2 = new hrdepartment ("Human Resources Department"); root-> Add (leaf1); root-> Add (leaf2 ); // branch company * mid1 = new concretecompany ("branch a"); company * leaf3 = new financedepartment ("Finance Department "); company * leaf4 = new hrdepartment ("Human Resources Department"); mid1-> Add (leaf3); mid1-> Add (leaf4); root-> Add (mid1 ); // branch company * mid2 = new concretecompany ("Branch B"); financedepartment * leaf5 = new financedepartment ("Finance Department "); hrdepartment * leaf6 = new hrdepartment ("Human Resources Department"); mid2-> Add (leaf5); mid2-> Add (leaf6); root-> Add (mid2 ); root-> show (0); Delete leaf1; Delete leaf2; Delete leaf3; Delete leaf4; Delete leaf5; Delete leaf6; Delete mid1; Delete mid2; Delete root; return 0 ;}
 

The disadvantage of the above implementation method is that the memory is not released well and the customer needs to do it on their own, which is very inconvenient. To be improved, it is better to release the concretecompany class. Because all pointers exist in the linked list of the concretecompany class. C ++ is troublesome and there is no garbage collection mechanism.

I have a blogArticleCopyright, reprint please indicate the source of http://blog.csdn.net/wuzhekai1985