Design Patterns: Solidify Your C# Application Architecture with Design Patterns中文版(下篇)

  1<iostream>
  2
  3#include <list>
  4
  5using namespace std; 
  6
  7class Shape 
  8
  9{ 
 10
 11public: 
 12
 13virtual void Draw(){}; 
 14
 15}; 
 16
 17class Line : public Shape 
 18
 19{ 
 20
 21private: 
 22
 23double x1, y1, x2, y2; 
 24
 25public: 
 26
 27Line(double x1, double y1, double x2, double y2) 
 28
 29{ 
 30
 31this-&gt;x1 = x1; 
 32
 33this-&gt;y1 = y1; 
 34
 35this-&gt;x2 = x2; 
 36
 37this-&gt;y2 = y2; 
 38
 39} 
 40
 41void Draw() 
 42
 43{ 
 44
 45//从(x1, y1) 到(x2, y2)画一条线 
 46
 47cout&lt;&lt;"Drawing a line"&lt;<endl; :="" circle="" circle(double="" class="" double="" private:="" public="" public:="" r;="" radius)="" shape="" this-="" x,="" y,="" {="" }="" };="">x = x; 
 48
 49this-&gt;y = y; 
 50
 51this-&gt;r = r; 
 52
 53} 
 54
 55void Draw() 
 56
 57{ 
 58
 59//以(x, y)为圆心，r为半径画一个圆 
 60
 61cout&lt;&lt;"Drawing a circle"&lt;<endl; :="" class="" drawing="" list<shape*="" private:="" public="" shape="" {="" }="" };=""> shapes; 
 62
 63list<shape*>::iterator it; 
 64
 65public: 
 66
 67Drawing() 
 68
 69{ 
 70
 71} 
 72
 73~Drawing() 
 74
 75{ 
 76
 77for (it = shapes.begin(); it != shapes.end(); it++) 
 78
 79{ 
 80
 81if (*it) 
 82
 83{ 
 84
 85delete *it; 
 86
 87*it = NULL; 
 88
 89} 
 90
 91} 
 92
 93shapes.clear(); 
 94
 95} 
 96
 97void Add(Shape* s) 
 98
 99{ 
100
101shapes.push_back(s); 
102
103} 
104
105void Draw() 
106
107{ 
108
109for (it = shapes.begin(); it != shapes.end(); it++) 
110
111{ 
112
113(dynamic_cast<shape*>(*it))-&gt;Draw(); 
114
115} 
116
117} 
118
119}; 
120
121int _tmain(int argc, _TCHAR* argv[]) 
122
123{ 
124
125Line* line = new Line(0, 0, 10, 12); 
126
127Circle* circle = new Circle(2, 3, 5.5); 
128
129Drawing* dwg = new Drawing(); 
130
131dwg-&gt;Add(new Line(3, 4, 3, 5)); 
132
133dwg-&gt;Add(new Circle(5, 6, 7.7)); 
134
135Shape* array[3] = {line, circle, dwg}; 
136
137// 画出所有的图形，注意：用一致的方式来访问所有对象 
138
139for (int i = 0; i &lt; 3; ++i) 
140
141{ 
142
143array[i]-&gt;Draw(); 
144
145delete array[i]; 
146
147} 
148
149return 0; 
150
151} 
152
153/*以下是程序输出结果： 
154
155Drawing a line 
156
157Drawing a circle 
158
159Drawing a line 
160
161Drawing a circle 
162
163*/ 
164
165】 
166
167** state  **
168
169每一位开发人员在他（她）的职业生涯里都至少实现过一次有限状态机。你无法躲避它们，它们无处不在，并且并不仅仅局限于软件开发领域。关于确定性有限自动机的设计和实现方面的文献随处可见也是不足为奇的。谈到有限状态机，我常常惊讶地看到设计上糟糕的、实现上充满bug的、根本不考虑扩展性的案例。可以向有限自动机中加入更多状态的能力通常是不成文的要求。当需要加入更多的状态和转换时，常常需要修改实现。如果设计良好，你就能够预见和处理这种变化。更重要的是，有限状态机中的任何状态的行为和操作细节都只应该被限制于对该状态的表示上。换句话说，状态细节代码应该驻留在实现该状态的对象里，这就易于加入新状态并易于转换。 
170
171基于表查找的方式是有限状态机的一个流行的设计方式。一个表映射了所有可能的输入到状态转换（即可能会导致有限状态机变换到另一个状态的转换）。不用说，尽管这种方式比较简单，但如果不对现有的实现代码作重大修改的话，是不可能适应变化的需求的。一个更好的替代方案是使用state设计模式。 
172
173假设用软件来实现一个碳酸饮料自动贩卖机，这个机器只接受5分、10分和25分的硬币，当投币分值累积到或超过25分时，即发出一罐饮料。每一次向槽内投入硬币，都会导致自动贩卖机转换到一个不同的状态，直到投币数达到所需的数量，此时机器会发出一罐饮料并重置回Start状态。表10代码定义了一个抽象类State，它代表自动贩卖机所能变换的所有状态的基类。 
174
175表  10 
176
177abstract class State 
178
179{ 
180
181public virtual void AddNickel(VendingMachine vm){ } 
182
183public virtual void AddDime(VendingMachine vm){ } 
184
185public virtual void AddQuarter(VendingMachine vm){ } 
186
187protected virtual void ChangeState(VendingMachine vm, State s) 
188
189{ 
190
191vm.ChangeState(s); 
192
193} 
194
195}   
196  
197---  
198  
199所有5个状态都从该基类派生并重载相应的虚方法。例如，当自动贩卖机处于Start状态时，投入一个5分硬币，则机器变为Five状态，如果再投入一个5分硬币，则切换为Ten状态。这就把转换逻辑分离到每一个实现状态的对象中。表11展示了实现状态的两个类。 
200
201表  11 
202
203class Start : State 
204
205{ 
206
207private static State state = new Start(); 
208
209private Start() 
210
211{ 
212
213} 
214
215public static State Instance() 
216
217{ 
218
219// singleton逻辑 
220
221Console.WriteLine("Credit: 0c"); 
222
223return state; 
224
225} 
226
227public override void AddNickel(VendingMachine vm) 
228
229{ 
230
231ChangeState(vm, Five.Instance()); 
232
233} 
234
235public override void AddDime(VendingMachine vm) 
236
237{ 
238
239ChangeState(vm, Ten.Instance()); 
240
241} 
242
243public override void AddQuarter(VendingMachine vm) 
244
245{ 
246
247vm.Vend(); 
248
249} 
250
251} 
252
253class Five : State 
254
255{ 
256
257private static State state = new Five(); 
258
259private Five() 
260
261{ 
262
263} 
264
265public static State Instance() 
266
267{ 
268
269// singleton逻辑 
270
271Console.WriteLine("Credit: 5c"); 
272
273return state; 
274
275} 
276
277public override void AddNickel(VendingMachine vm) 
278
279{ 
280
281ChangeState(vm, Ten.Instance()); 
282
283} 
284
285public override void AddDime(VendingMachine vm) 
286
287{ 
288
289ChangeState(vm, Fifteen.Instance()); 
290
291} 
292
293public override void AddQuarter(VendingMachine vm) 
294
295{ 
296
297vm.Vend(); 
298
299ChangeState(vm, Start.Instance()); // no change returned :-) 
300
301} 
302
303}   
304  
305---  
306  
307自动贩卖机不必关心状态转换逻辑，它只管用当前state实例进行操作，这样，就彻底和有关状态细节解耦。参见表12。 
308
309表  12 
310
311class VendingMachine 
312
313{ 
314
315private State state; 
316
317public VendingMachine() 
318
319{ 
320
321Console.WriteLine("The Vending Machine is now online: product costs 25c"); 
322
323state = Start.Instance(); 
324
325} 
326
327public void ChangeState(State to) 
328
329{ 
330
331state = to; 
332
333} 
334
335public void Vend() 
336
337{ 
338
339// 发饮料 
340
341Console.WriteLine("Dispensing product...Thank you!"); 
342
343} 
344
345public void AddNickel() 
346
347{ 
348
349state.AddNickel(this); 
350
351} 
352
353public void AddDime() 
354
355{ 
356
357state.AddDime(this); 
358
359} 
360
361public void AddQuarter() 
362
363{ 
364
365state.AddQuarter(this); 
366
367} 
368
369}   
370  
371---  
372  
373我已经说明了state模式优于简单的、基于表查找的实现方式。总之，这种设计模式有助于将状态细节行为局部化于实现具体状态的类中，因此促进了软件的重用和扩展。这也避免了在程序代码中四处乱写条件语句的需要，而那将使维护代码的程序员苦不堪言，现实中，这些负责维护的程序员的人数远远多于最初的实现者。</shape*></shape*></endl;></endl;></list></iostream>