I understand the design pattern (C ++ implementation) -- decorator pattern)

Solved problems:

We bought several abstract paintings when decorating our new home. After buying them, we found that some colored borders are more suitable for us, while some of them are more suitable for our use. How can we solve this problem? He needs to dynamically add additional responsibilities to other objects, which is the purpose of the Paster mode.

We can add new functions to the original object by means of inheritance, but the decoration mode is more flexible than the subclass generation by means of combination.

Class chart and sample implementation:

In the decoration mode, the roles are:

Abstract component role: provides an abstract interface to standardize the objects that are prepared to receive additional responsibilities.

Concrete component role: defines a class that will receive additional responsibilities.

Decorator: holds an instance of a component object and defines an interface consistent with the abstract Component Interface.

Concrete decorator: attaches "additional responsibilities to the component object.

[CPP]View plaincopy

1. # Include <string>
2. # Include <iostream>
3. # Include <memory>
4. Using namespace STD;
6. // Abstract class Tank
7. Class Tank
8. {
9. Public:
10. Virtual void shot () = 0;
11. Virtual void run () = 0;
13. Public:
14. Virtual ~ Tank ()
15. {
16. Cout <"in the destructor of Tank" <Endl;
17. }
18. };
19. // Specific class T50
20. Class T50: Public Tank
21. {
22. Public:
23. Void shot ()
24. {
25. Cout <"tank T50 shot ()" <Endl;
26. }
27. Void run ()
28. {
29. Cout <"tank T50 run ()" <Endl;
30. }
31. Public:
32. Virtual ~ T50 ()
33. {
34. Cout <"in the destructor of T50" <Endl;
35. }
36. };
37. // Specific class T75
38. Class T75: Public Tank
39. {
40. Public:
41. Void shot ()
42. {
43. Cout <"tank T75 shot ()" <Endl;
44. }
45. Void run ()
46. {
47. Cout <"tank T75 run ()" <Endl;
48. }
49. Public:
50. Virtual ~ T75 ()
51. {
52. Cout <"in the destructor of T75" <Endl;
53. }
54. };
56. // Abstract class, decorator
57. Class decorator: Public Tank
58. {
59. Protected:
60. Tank * tank;
61. Public:
62. Decorator (tank * tank): tank (tank) {}// decoration class of the specific tank
63. Virtual ~ Decorator ()
64. {
65. Cout <"in the destructor of decorator" <Endl;
66. }
67. Public:
68. Void shot ()
69. {
70. Tank-> shot ();
71. }
72. Void run ()
73. {
74. Tank-> Run ();
75. }
76. };
78. Class infrareddecorator: Public decorator
79. {
80. PRIVATE:
81. String infrared; // This is the so-called addatrried
82. Public:
83. Infrareddecorator (tank * tank): decorator (tank ){}
84. Virtual ~ Infrareddecorator ()
85. {
86. Cout <"in the destructor of infrareddecorator" <Endl;
87. }
88. Public:
89. Void set_infrared (const string & infrared)
90. {
91. This-> infrared = infrared;
92. }
93. String get_infrared () const
94. {
95. Return infrared;
96. }
97. Void run ()
98. {
99. Tank-> Run ();
100. Set_infrared ("+ infrared ");
101. Cout <get_infrared () <Endl;
102. }
103. Void shot ()
104. {
105. Tank-> shot ();
106. }
107. };
109. Class amphibiandecorator: Public decorator
110. {
111. PRIVATE:
112. String amphibian;
113. Public:
114. Amphibiandecorator (tank * tank): decorator (tank ){}
115. ~ Amphibiandecorator ()
116. {
117. Cout <"in the destructor of amphibiandecorator" <Endl;
118. }
119. Public:
120. Void set_amphibian (const string & hibian)
121. {
122. This-> amphibian = hibian;
123. }
124. String get_amphibian () const
125. {
126. Return amphibian;
127. }
128. Public:
129. Void run ()
130. {
131. Tank-> Run ();
132. Set_amphibian ("+ amphibian ");
133. Cout <get_amphibian () <Endl;
134. }
135. Void shot ()
136. {
137. Tank-> shot ();
138. }
139. };
141. Int main (INT argc, char ** argv)
142. {
143. // Adds the infrared function to the t50.
144. Tank * tank1 (New T50 );
145. Tank * pid1 (New infrareddecorator (tank1 ));
146. Pid1-> shot ();
147. Cout <Endl;
148. Pid1-> Run ();
149. Cout <Endl;
150. Cout <Endl <"---------------" <Endl;
151. // Adds infrared and amphibious functions to T75
152. Tank * tank2 (New T75 );
153. Tank2-> Run ();
154. Tank * pid2 (New infrareddecorator (tank2 ));
155. Tank * pad2 (New amphibiandecorator (pid2 ));
156. Pad2-> shot ();
157. Cout <Endl;
158. Pad2-> Run ();
159. Cout <Endl;
160. Cout <Endl <"--------------" <Endl;
162. // Dynamically undo other decorations?
163. Tank2-> Run ();
165. Tank * tank3 (tank2 );
166. Tank3-> Run ();
167. Return 0;
168. }

 

Differences between the modifier and the adapter:

1. About new responsibilities: the adapter can also add new responsibilities during the conversion, but the main purpose is not here. The decorator mode adds new responsibilities to the decorator.

2. Original interface: the adapter mode uses a new interface to call the original interface. The original interface is invisible or unavailable to the new system. The original interface is used in the decoration mode, and the system also uses the original interface for the decoration objects. (The modifier mode for adding new interfaces can be considered as its variant-"Translucent" modifier)

3. About the object of the package: the adapter knows the details of the adapter (that is, the class or the interface ). The decorator only knows what its interface is. The specific type (whether it is a base class or another derived class) is only known during running.

Key points:

1. the decorator and the decorated object have the same super type.

2. One or more decorators can wrap an object.

3. the decorator Can add his/her own actions before or after the actions of the entrusted decorator to achieve a specific purpose.

4. objects can be decorated at any time, so they can be dynamically decorated at runtime. You can use your favorite decorator to decorate objects in an unlimited number.

5. In the decoration mode, the key to inheritance is to match the type of the modifier and the decorated object, rather than obtaining its behavior.

6. the decorator is generally transparent to the customer of the component, unless the customer program depends on the specific type of the component. In actual projects, you can add new behaviors to the decorator as needed to achieve "Translucent.

Applicable scenarios and advantages and disadvantages: The decoration mode should be used in the following situations:

1. You need to extend the functions of a class or add additional responsibilities to a class.

2. You need to dynamically add functions to an object. These functions can be dynamically revoked.

3. A large number of functions are generated by the arrangement and combination of some basic functions to make the inheritance relationship unrealistic.

Advantages:

1. The purpose of the decorator mode and the inheritance relationship is to expand the object functions, but the decorator can provide more flexibility than inheritance.

2. By using different specific decorative classes and the arrangement and combination of these decorative classes, designers can create a combination of many different behaviors.

Disadvantages:

1. This is more flexible than inheritance, and it also means more complexity.

2. The decoration mode will lead to many small classes in the design. Excessive use will complicate the program.

3. The decoration mode is designed for the component type. However, if you want to program specific components, you should rethink your application architecture and whether the decorator is appropriate. Of course, you can also change the Component Interface, add new public behavior, and implement the "Translucent" modifier mode. Make the best choice in the actual project.