Design Patterns: Solidify Your C# Application Architecture with Design Patterns中文版(下篇)
作者：Samir Bajaj
译者：荣耀
【译序：C#进阶文章。译者对Samir提供的C#例子进行了简单整理（作者提供的某些代码在译者的环境中无法通过编译），并编写了对应的C++示例，一并置于译注中，以便读者比对。译文中所有C#、C++程序调试环境均为Microsoft Visual Studio.NET 7.0 Beta2】
C++示例：
#include "stdafx.h";
#include <iostream>
#include <list>
using namespace std;
class Shape
{
public:
virtual void Draw(){};
};
class Line : public Shape
{
private:
double x1, y1, x2, y2;
public:
Line(double x1, double y1, double x2, double y2)
{
this->x1 = x1;
this->y1 = y1;
this->x2 = x2;
this->y2 = y2;
}
void Draw()
{
//从(x1, y1) 到(x2, y2)画一条线
cout<<"Drawing a line"<<endl;
}
};
class Circle : public Shape
{
private:
double x, y, r;
public:
Circle(double x, double y, double radius)
{
this->x = x;
this->y = y;
this->r = r;
}
void Draw()
{
//以(x, y)为圆心，r为半径画一个圆
cout<<"Drawing a circle"<<endl;
}
};
class Drawing : public Shape
{
private:
list<Shape*> shapes;
list<Shape*>::iterator it;
public:
Drawing()
{
}
~Drawing()
{
for (it = shapes.begin(); it != shapes.end(); it++)
{
if (*it)
{
delete *it;
*it = NULL;
}
}
shapes.clear();
}
void Add(Shape* s)
{
shapes.push_back(s);
}
void Draw()
{
for (it = shapes.begin(); it != shapes.end(); it++)
{
(dynamic_cast<Shape*>(*it))->Draw();
}
}
};
int _tmain(int argc, _TCHAR* argv[])
{
Line* line = new Line(0, 0, 10, 12);
Circle* circle = new Circle(2, 3, 5.5);
Drawing* dwg = new Drawing();
dwg->Add(new Line(3, 4, 3, 5));
dwg->Add(new Circle(5, 6, 7.7));
Shape* array[3] = {line, circle, dwg};
// 画出所有的图形，注意：用一致的方式来访问所有对象
for (int i = 0; i < 3; ++i)
{
array[i]->Draw();
delete array[i];
}
return 0;
}
/*以下是程序输出结果：
Drawing a line
Drawing a circle
Drawing a line
Drawing a circle
*/
】
state
每一位开发人员在他（她）的职业生涯里都至少实现过一次有限状态机。你无法躲避它们，它们无处不在，并且并不仅仅局限于软件开发领域。关于确定性有限自动机的设计和实现方面的文献随处可见也是不足为奇的。谈到有限状态机，我常常惊讶地看到设计上糟糕的、实现上充满bug的、根本不考虑扩展性的案例。可以向有限自动机中加入更多状态的能力通常是不成文的要求。当需要加入更多的状态和转换时，常常需要修改实现。如果设计良好，你就能够预见和处理这种变化。更重要的是，有限状态机中的任何状态的行为和操作细节都只应该被限制于对该状态的表示上。换句话说，状态细节代码应该驻留在实现该状态的对象里，这就易于加入新状态并易于转换。
基于表查找的方式是有限状态机的一个流行的设计方式。一个表映射了所有可能的输入到状态转换（即可能会导致有限状态机变换到另一个状态的转换）。不用说，尽管这种方式比较简单，但如果不对现有的实现代码作重大修改的话，是不可能适应变化的需求的。一个更好的替代方案是使用state设计模式。
假设用软件来实现一个碳酸饮料自动贩卖机，这个机器只接受5分、10分和25分的硬币，当投币分值累积到或超过25分时，即发出一罐饮料。每一次向槽内投入硬币，都会导致自动贩卖机转换到一个不同的状态，直到投币数达到所需的数量，此时机器会发出一罐饮料并重置回Start状态。表10代码定义了一个抽象类State，它代表自动贩卖机所能变换的所有状态的基类。
表10
abstract class State
{
public virtual void AddNickel(VendingMachine vm){ }
public virtual void AddDime(VendingMachine vm){ }
public virtual void AddQuarter(VendingMachine vm){ }
protected virtual void ChangeState(VendingMachine vm, State s)
{
vm.ChangeState(s);
}
}
所有5个状态都从该基类派生并重载相应的虚方法。例如，当自动贩卖机处于Start状态时，投入一个5分硬币，则机器变为Five状态，如果再投入一个5分硬币，则切换为Ten状态。这就把转换逻辑分离到每一个实现状态的对象中。表11展示了实现状态的两个类。
表11
class Start : State
{
private static State state = new Start();
private Start()
{
}
public static State Instance()
{
// singleton逻辑
Console.WriteLine("Credit: 0c");
return state;
}
public override void AddNickel(VendingMachine vm)
{
ChangeState(vm, Five.Instance());
}
public override void AddDime(VendingMachine vm)
{
ChangeState(vm, Ten.Instance());
}
public override void AddQuarter(VendingMachine vm)
{
vm.Vend();
}
}
class Five : State
{
private static State state = new Five();
private Five()
{
}
public static State Instance()
{
// singleton逻辑
Console.WriteLine("Credit: 5c");
return state;
}
public override void AddNickel(VendingMachine vm)
{
ChangeState(vm, Ten.Instance());
}
public override void AddDime(VendingMachine vm)
{
ChangeState(vm, Fifteen.Instance());
}
public override void AddQuarter(VendingMachine vm)
{
vm.Vend();
ChangeState(vm, Start.Instance()); // no change returned :-)
}
}
自动贩卖机不必关心状态转换逻辑，它只管用当前state实例进行操作，这样，就彻底和有关状态细节解耦。参见表12。
表12
class VendingMachine
{
private State state;
public VendingMachine()
{
Console.WriteLine("The Vending Machine is now online: product costs 25c");
state = Start.Instance();
}
public void ChangeState(State to)
{
state = to;
}
public void Vend()
{
// 发饮料
Console.WriteLine("Dispensing product...Thank you!");
}
public void AddNickel()
{
state.AddNickel(this);
}
public void AddDime()
{
state.AddDime(this);
}
public void AddQuarter()
{
state.AddQuarter(this);
}
}
我已经说明了state模式优于简单的、基于表查找的实现方式。总之，这种设计模式有助于将状态细节行为局部化于实现具体状态的类中，因此促进了软件的重用和扩展。这也避免了在程序代码中四处乱写条件语句的需要，而那将使维护代码的程序员苦不堪言，现实中，这些负责维护的程序员的人数远远多于最初的实现者。
