从一个计算器开始说起——C#中的工厂方法模式
从一个计算器开始说起——C#中的工厂方法模式
工厂模式作为很常见的设计模式，在日常工作中出镜率非常高，程序员们一定要掌握它的用法哟，今天跟着老胡一起来看看吧。
举个例子
现在先让我们来看一个例子吧，比如，要开发一个简单的计算器，完成加减功能，通过命令行读入形如1+1的公式，输出2这个结果，让我们看看怎么实现吧。
第一个版本
这个版本里面，我们不考虑使用模式，就按照最简单的结构，怎么方便怎么来。
思路非常简单，仅需要实现以下几个方法
- 取运算数
- 取运算符
- 输出结果
class Program
{
static int GetOperatorIndex(string input)
{
int operatorIndex = 0;
for (; operatorIndex < input.Length; operatorIndex++)
{
if (!char.IsDigit(input[operatorIndex]))
break;
}
return operatorIndex;
}
static int GetOp(string input, int startIndex, int size = -1)
{
string subStr;
if (size == -1)
{
subStr = input.Substring(startIndex);
}
else
{
subStr = input.Substring(startIndex, size);
}
return int.Parse(subStr);
}
static int CalculateExpression(string input)
{
var operatorIndex = GetOperatorIndex(input); //得到运算符索引
var op1 = GetOp(input, 0, operatorIndex); //得到运算数1
var op2 = GetOp(input, operatorIndex + 1); //得到运算数2
switch (input[operatorIndex])
{
case '+':
return op1 + op2;
case '-':
return op1 - op2;
default:
throw new Exception("not support");
}
}
static void Main(string[] args)
{
string input = Console.ReadLine();
while(!string.IsNullOrEmpty(input))
{
var result = CalculateExpression(input);
Console.WriteLine("={0}", result);
input = Console.ReadLine();
}
}
}
代码非常简单，毋庸置疑，这个运算器是可以正常工作的。这也可能是我们大部分人刚刚踏上工作岗位的时候可能会写出的代码。但它有着以下这些缺点：
- 缺乏起码的抽象，至少加和减应该能抽象出操作类。
- 缺乏抽象造成了巨型客户端，所有的逻辑都嵌套在了客户端里面。
- 使用switch case缺乏扩展性，同时switch case也暗指了这部分代码是属于变化可能性比较高的地方，我们应该把它们封装起来。而且不能把他们放在和客户端代码一起
接下来，我们引入我们的主题，工厂方法模式。
工厂方法模式版本
工厂方法模式使用一个虚拟的工厂来完成产品构建（在这里是运算符的构建，因为运算符是我们这个程序中最具有变化的部分），通过把可变化的部分封装在工厂类中以达到隔离变化的目的。我们看看UML图：
依葫芦画瓢，我们设计思路如下：
- 设计一个IOperator接口，对应抽象的Product
- 设计AddOperator和SubtractOperator，对应具体Product
- 设计IOperatorFactory接口生产Operator
- 设计OperatorFactory实现抽象IFactory
关键代码如下，其他读取操作数之类的代码就不在赘述。
- IOperator接口
interface IOperator
{
int Calculate(int op1, int p2);
}
- 具体Operator
class AddOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 + op2;
}
}
class SubtractOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 - op2;
}
}
- Factory接口
interface IOperatorFactory
{
IOperator CreateOperator(char c);
}
- 具体Factory
class OperatorFactory : IOperatorFactory
{
public IOperator CreateOperator(char c)
{
switch(c)
{
case '+':
return new AddOperator();
case '-':
return new SubtractOperator();
default:
throw new Exception("Not support");
}
}
}
- 在CalculateExpression里面使用他们
static IOperator GetOperator(string input, int operatorIndex)
{
IOperatorFactory f = new OperatorFactory();
return f.CreateOperator(input[operatorIndex]);
}
static int CalculateExpression(string input)
{
var operatorIndex = GetOperatorIndex(input);
var op1 = GetOp(input, 0, operatorIndex);
var op2 = GetOp(input, operatorIndex + 1);
IOperator op = GetOperator(input, operatorIndex);
return op.Calculate(op1, op2);
}
这样，我们就用工厂方法重新写了一次计算器，现在看看，好处有
- 容易变化的创建部分被工厂封装了起来，工厂和客户端以接口的形式依赖，工厂内部逻辑可以随时变化而不用担心影响客户端代码
- 工厂部分可以放在另外一个程序集，项目规划会更加合理
- 客户端仅仅需要知道工厂和抽象的产品类，不需要再知道每一个具体的产品（不需要知道如何构建每一个具体运算符），符合迪米特法则
- 扩展性增强，如果之后需要添加乘法multiple，那么仅需要添加一个Operator类代表Multiple并且修改Facotry里面的生成Operator逻辑就可以了，不会影响到客户端
自此，我们已经在代码里面实现了工厂方法模式，但可能有朋友就会想，虽然现在扩展性增强了，但是新添加运算符还是需要修改已有的工厂，这不是违反了开闭原则么。。有没有更好的办法呢？当然是有的。
反射版本
想想工厂方法那个版本，我们为什么增加新的运算符就会不可避免的修改现有工厂？原因就是我们通过switch case来硬编码“教导”工厂如何根据用户输入产生正确的运算符，那么如果有一种方法可以让工厂自动学会发现新的运算符，那么我们的目的不就达到了？
嗯，我想聪明的朋友们已经知道了，用属性嘛，在C#中，这种方法完成类的自描述，是最好不过了的。
我们的设计思路如下：
- 定义一个描述属性以识别运算符
- 在运算符中添加该描述属性
- 在工厂启动的时候，扫描程序集以注册所有运算符
代码如下：
- 描述属性
class OperatorDescriptionAttribute : Attribute
{
public char Symbol { get; }
public OperatorDescriptionAttribute(char c)
{
Symbol = c;
}
}
- 添加描述属性到运算符
[OperatorDescription('+')]
class AddOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 + op2;
}
}
[OperatorDescription('-')]
class SubtractOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 - op2;
}
}
- 让工厂使用描述属性
class OperatorFactory : IOperatorFactory
{
private Dictionary<char, IOperator> dict = new Dictionary<char, IOperator>();
public OperatorFactory()
{
Assembly assembly = Assembly.GetExecutingAssembly();
foreach (var type in assembly.GetTypes())
{
if (typeof(IOperator).IsAssignableFrom (type)
&& !type.IsInterface)
{
var attribute = type.GetCustomAttribute<OperatorDescriptionAttribute>();
if(attribute != null)
{
dict[attribute.Symbol] = Activator.CreateInstance(type) as IOperator;
}
}
}
}
public IOperator CreateOperator(char c)
{
if(!dict.ContainsKey(c))
{
throw new Exception("Not support");
}
return dict[c];
}
}
经过这种改造，现在程序对扩展性支持已经很友好了，需要添加Multiple，只需要添加一个Multiple类就可以，其他代码都不用修改，这样就完美符合开闭原则了。
[OperatorDescription('*')]
class MultipleOperator : IOperator
{
public int Calculate(int op1, int op2)
{
return op1 * op2;
}
}
这就是我们怎么一步步从最原始的代码走过来，一点点重构让代码实现工厂方法模式，最终再完美支持开闭原则的过程，希望能帮助到大家。
其实关于最后那个通过标记属性实现扩展，微软有个MEF框架支持的很好，原理跟这个有点相似，有机会我们再聊聊MEF。
漫思
