2.工厂方法模式

为什么使用工厂方法模式？

在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有这比较稳定的接口。如何应对这种变化？如何提供一种“封装机制”来隔离出 “这个易变对象” 的变化，从而保持系统中的 “其他依赖改对象” 不随这需求的改变而改变呢？

工厂方法模式通过面向对象的手法，将所要创建的具体对象工作延迟到子类，从而实现一种扩展（而非更改）的策略，较好地解决了这种紧耦合的关系。

 

结构

1. 产品 （Product） 将会对接口进行声明。 对于所有由创建者及其子类构建的对象， 这些接口都是通用的。
2. 具体产品 （Concrete Products） 是产品接口的不同实现。
3. 创建者 （Creator） 类声明返回产品对象的工厂方法。 该方法的返回对象类型必须与产品接口相匹配。
   你可以将工厂方法声明为抽象方法， 强制要求每个子类以不同方式实现该方法。 或者， 你也可以在基础工厂方法中返回默认产品类型。
   PS：虽然它的名字是创建者， 但他最主要的职责并不是创建产品。一般来说， 创建者类包含一些与产品相关的核心业务逻辑。 工厂方法将这些逻辑处理从具体产品类中分离出来。 比如，你们公司有一个给程序员培训的部门。 但是， 公司的主要工作还是编写代码， 而非培训程序员。
4. 具体创建者 （Concrete Creators） 将会重写基础工厂方法， 使其返回不同类型的产品。
   PS: 并不一定每次调用工厂方法都会创建新的实例。 工厂方法也可以返回缓存、 对象池或其他来源的已有对象。

 

实现方式

1. 让所有产品都遵循同一接口。 该接口必须声明对所有产品都有意义的方法。（所有子类都能用上）
2. 在创建类中添加一个空的工厂方法。 该方法的返回类型必须遵循通用的产品接口。(上面声明的那个接口)
3. 在创建类代码中找到对于构造函数的所有引用。 将它们依次替换为对于工厂方法的调用， 同时将创建方法(new)的代码移入工厂方法。
4. 为工厂方法中的每种产品编写一个工厂子类， 然后在子类中重写工厂方法， 并将基本方法中的相关创建代码移动到工厂方法中。
5. 如果应用中的产品类型太多， 那么为每个产品创建子类工作量就很大， 这时你也可以在子类中在找出几个类的共同点创建一个基类。

示例

/// <summary>
/// 车的抽象(接口)
/// </summary>
public abstract class Car
{
    /// <summary>
    /// 启动
    /// </summary>
    public abstract void StartUp();

    /// <summary>
    /// 转向
    /// </summary>
    public abstract void Turn();

    /// <summary>
    /// 停车
    /// </summary>
    public abstract void Stop();
}
/// <summary>
/// 车工厂
/// </summary>
public abstract class CarFactory
{
    /// <summary>
    /// 创建车
    /// </summary>
    public abstract Car CreateCar();
}
/// <summary>
/// 吉普车
/// </summary>
class JiPuCar : Car
{
    public override void StartUp()
    {
        Console.WriteLine("--- 吉普车 启动 ---");
    }

    public override void Stop()
    {
        Console.WriteLine("--- 吉普车 停下 ---");
    }

    public override void Turn()
    {
        Console.WriteLine("--- 吉普车 转向 ---");
    }
}
/// <summary>
/// 吉普车工厂
/// </summary>
public class JiPuCarFactory : CarFactory
{

    // 若只需要测试一种车完全没有必要使用工厂方法设计模式,
    // 直接在测试对象中写 Car c = new Car(); 就可以了.

    // 若需要测试固定类型(数量)的车也不需要使用工厂方法设计模式,
    // 直接将测试方法中new 或者作为参数传进来就可以了.

    // 当需要测试不定类型(数量)的车时, 才符合使用这种设计模式.
    public override Car CreateCar()
    {
        return new JiPuCar();
    }
}

按照此逻辑，如果有新的车，只需要实现对应的具体车类和对应的工厂类即可，保证有需求只需要拓展而不需要修改现有的代码。 

 

优缺点

优点：

1. 你可以避免创建者和具体产品之间的紧密耦合。
2. 单一职责原则。 你可以将产品创建代码放在程序的单一位置， 从而使得代码更容易维护。
3. 开闭原则。 无需更改现有客户端代码， 你就可以在程序中引入新的产品类型。

缺点：

1. 应用工厂方法模式需要引入许多新的子类， 代码可能会因此变得更复杂。 最好的情况是将该模式引入创建者类的现有层次结构中。