设计模式（五）工厂方法模式

工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。但缺点是由于每加一个产品，就需要加一个产品工厂的类，增加了额外的开发量。

【例】简单计算器的运算

简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对应客户端来说，去除了与具体产品的依赖。如果要增加一个 “求M数的N次方” 的功能，我们是一定需要给运算工厂类的方法里加 ‘Case’ 的分支条件，修改原有的类。这就违背了开放-封闭原则。

工厂方法模式代码

// 工厂接口
interface IFactory
{
  Operation CreateOperation();
}

// 具体工厂
class AddFactory : IFactory
{
  public Operation CreateOperation()
  {
    return new OperationAdd();
  }
}
class SubFactory : IFactory
{
  public Operation CreateOperation()
  {
    return new OperationSub();
  }
}
class MulFactory : IFactory
{
  public Operation CreateOperation()
  {
    return new OperationMul();
  }
}
class DivFactory : IFactory
{
  public Operation CreateOperation()
  {
    return new OperationDiv();
  }
}

// 客户端
IFactory operation = new AddFactory();
Operation oper = operFactory.CreateOperation();
oper.NumberA = 1;
oper.NumberB = 2;
double result = oper.GetResult();

根据依赖倒转原则，我们把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的工厂方法。然后，所有的要生产具体类的工厂，就去实现这个接口，这样，一个简单工厂模式的工厂类，变成了一个工厂抽象接口和多个具体生成对象的工厂，于是我们要增加 “求M数的N次方” 的功能时，就不需要更改原有的工厂类了，只需要增加此功能的运算类和相应的工厂类就可以了。

 

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。想要添加功能，本来是改工厂类的，而现在是修改客户端。