本文共 3482 字，大约阅读时间需要 11 分钟。

别名：虚拟构造器、Factory Method

一，意图

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

---

二，动机

   在软件系统中，经常面临着"某个对象‘’的创建工作；由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有这比较稳定的接口。

问题来了：

    如何应对这种变化？如何提供一种“封装机制”来隔离出 “这个易变对象” 的变化，从而保持系统中的 “其他依赖改对象” 不随这需求的改变而改变呢？

举例理解：

  绝地求生中有很多车（轿车，吉普车，蹦蹦等），我现在需要一个测试车工具类，测试这些车的功能（启动，转向，停止等）。而这个车测试类需要可以测试所有满足车的抽象类的车的具体类（即便后面在增加几种类型，这个测试类也不需要改变）。

解决方案：

  创建一个车类型的接口和车类型的工厂接口。然后每种具体的车(轿车，吉普…)都去实现车类型的接口，然后在创建一个自己的工厂并实现类型的工厂接口。   这样不管后面需要增加什么样的车，只有他满足车的接口都可以按照这这种方式实现。

归纳总结：

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

---

三，结构

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

---

四，优缺点

优点：

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

缺点：

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

---

五，应用场景

适用性：

• 当一个类不知道它所必须创建对象的类的时候
• 当一个类希望由它的子类来指定它所创建的对象的时候
• 当你在写代码的过程中， 如果无法预知对象确切类别及其依赖关系时， 可使用工厂方法。( 例如， 如果需要向应用中添加一种新产品， 你只需要开发新的创建者子类， 然后重写其工厂方法即可。)

对照：

• 工厂方法模式解决“单个对象”的需求变化；
• 抽象工厂模式解决“系列对象”的需求变化；
• 生成器模式  解决“对象部分”的需求变化；

工厂方法模式主要用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型，紧耦合关系会导致程序的脆弱。

---

六，代码实现

实现方式：

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

示例代码：

1. 还是以上面说的那个测试车为例：首先有个抽象车类(此类包含的所有声明必顶对所有子类都有意义【比如：声明了一个测试耗油量的方法，若此时你需要测试的车中有电动车，那么这个方法就不应该声明在抽象类(接口)中】)

/// 
/// 车的抽象(接口)/// 
public abstract class Car{
       /// 
    /// 启动    /// 
    public abstract void StartUp();    /// 
    /// 转向    /// 
    public abstract void Turn();    /// 
    /// 停车    /// 
    public abstract void Stop();}

2. 创建一个工厂方法接口

/// 
/// 车工厂/// 
public abstract class CarFactory{
       /// 
    /// 创建车    /// 
    public abstract Car CreateCar();}

3.创建具体车类 – 实现1创建接口

/// 
/// 吉普车/// 
class JiPuCar : Car{
       public override void StartUp()    {
           Console.WriteLine("--- 吉普车 启动 ---");    }    public override void Stop()    {
           Console.WriteLine("--- 吉普车 停下 ---");    }    public override void Turn()    {
           Console.WriteLine("--- 吉普车 转向 ---");    }}

4.创建具体车类（对应3）的工厂类 – 实现2创建接口

/// 
/// 吉普车工厂/// 
public class JiPuCarFactory : CarFactory{
       // 若只需要测试一种车完全没有必要使用工厂方法设计模式,    // 直接在测试对象中写 Car c = new Car(); 就可以了.    // 若需要测试固定类型(数量)的车也不需要使用工厂方法设计模式,    // 直接将测试方法中new 或者作为参数传进来就可以了.    // 当需要测试不定类型(数量)的车时, 才符合使用这种设计模式.    public override Car CreateCar()    {
           return new JiPuCar();    }}

5. 放到测试框架中进行测试：

/// 
/// 车测试框架 -- 所有车都可以被测试/// 
class CarTestFramework{
       public void BuildTestCar(CarFactory carFactory)    {
           Car c1 = carFactory.CreateCar();        c1.StartUp();        c1.Turn();        c1.Stop();    }}

6.启动测试框架，查看测试结果

class Program{
       static void Main(string[] args)    {
           CarTestFramework carTestFramework = new CarTestFramework();        carTestFramework.BuildTestCar(new JiPuCarFactory());        Console.ReadKey();    }}

按照此逻辑，当再有其他车需要进行测试时，只需要按照3,4步骤中实现对应的具体车类和对应的工厂类即可，进行测试。这样就保证了有需求增加时只需要我们拓展（新建类）而不需要修改现有的代码。

---

设计模式系列文示例代码工程：

---

---

转载地址：https://czhenya.blog.csdn.net/article/details/114852782 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！