【一起学系列】之工厂模式：产品？产品族?

以你之姓@ 2023-02-12 11:21 3阅读 0赞

## 前言 ##

在设计模式中关于工厂模式有一点特殊，就标准意义而言我们一般提到的工厂模式一般包括三种：

*  简单工厂
 *  工厂方法模式
 *  抽象工厂模式

> ***其实简单工厂不属于设计模式，由于它的使用场景还是比较多的，因此本篇将会一起介绍一下~***

## 工厂模式意图 ##

工厂模式属于对象创建型模式，无论是上述三种的哪一种都是为了同一个设计原则即依赖抽象，不要依赖具体

简单来说就是把复杂对象创建（初始化）的细节或者依赖关系经常可能发生变化的细节交给一个第三方类（工厂类），避免在业务逻辑中书写不必要的内容

## 简单工厂模式的简单写法 ##

简单工厂在实际应用中非常的频繁，假设我们现在需要生产Intel和AMD相关的产品，来看看代码

### 静态方法无脑IF | Switch ###

public class SimpleFactory { 
    
        public static AbstractCPU createCpu (String type) { 
            switch (type) { 
                case "INTEL":
                    return new IntelCpu();
                default:
                    return new AMDCpu();
            }
    
           /* if ("INTEL".equals(type)) { return new IntelCpu(); } else if ("AMD".equals(type)){ return new AMDCpu(); } return null;*/
        }
    }

> ***此种方式适合非常单一的场景，快速构建工厂代码，不用过多的思考***

值得注意的是静态方法和普通方法的区别，静态工厂让它不具备继承性，在某些场合可能导致无法扩展的问题，在代码优化层面可以配合枚举，Map等方式继续让代码变得更清爽一些

## 工厂方法模式 ##

### 意图 ###

定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Mehod使一个类的实例化延迟到其子类

### 工厂方法模式的诞生 ###

工厂方法用来处理对象的创建，并将这样的行为封装在子类中，这样，客户程序中关于超类的代码就和子类对象创建代码解耦了。

咱们还是一样，说说人话：

【产品】：最近我们有英特尔和AMD的CPU产品订购方案，您看能不能实现一下相关的代码？

【BOSS】：它们的装配啊，生产啊等等的细节一样吗？

【产品】：嗯嗯，细节流程都是一样的！

【BOSS】：那个谁，小柯啊，工厂方法模式懂吗，去做吧，给你半天时间，好好设计设计。

![format_png][]

【开发】：好的！（内心OS：我不会啊！！！）

### HeadFirst 核心代码 ###

不会的话，只能看书学习啦~

**父级接口**

public abstract class Factory { 
    
        /*** * 产品订购方案 */
        public AbstractCPU orderCpu () { 
            AbstractCPU cpu = generateCpu();
            cpu.show();
            cpu.prepare();
            cpu.box();
    
            // 假设有相同的业务处理逻辑...
            return cpu;
        }
    
        protected abstract AbstractCPU generateCpu();
    }

**具体实现**

public class IntelCpuFactory extends Factory { 
    
        @Override
        public AbstractCPU generateCpu() { 
            return new IntelCpu();
        }
    }
    
    // ****************************************************************
    
    public class AMDCpuFactory extends Factory { 
    
        @Override
        public AbstractCPU generateCpu() { 
            return new AMDCpu();
        }
    }

工厂方法模式的设计思路：

*  Product（Document） 定义工厂方法所创建对象的接口
 *  ConcreteProduct（MyDocument）实现Product接口
 *  Creator（Factory）声明工厂方法
 *  ConcreteCreator（MyFactory）具体的工厂类

### 什么场景适用 ###

在下列情况下可以使用 Factory Method模式：

*  当一个类不知道它所必须创建的对象的类的时候
 *  当一个类希望由它的子类来指定它所创建的对象的时候
 *  当类将创建对象的职责委托给多个子类中的某一个，并且你希望控制哪一个子类实现的时候

### Code/生活中的实际应用 ###

例如在工厂生产电池时，对于电池的保管，订货，输送的方式可能完全一致，但是仅型号不一致，因此分别交给A流水线，B流水线进行生产，但是后续的其他流程又是重合的

### UML图 ###

![format_png 1][]

## 抽象工厂模式 ##

### 意图 ###

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类

### 抽象工厂模式的诞生 ###

PS：故事内容承接工厂方法模式的诞生~

【产品】：我… 我好像搞错需求了…

【BOSS】：什么意思？？？

【产品】：咱们的订单不是仅仅只生成CPU产品，而是要生成英特尔还有AMD的全系列产品…

![format_png 2][]

【BOSS】：你你你你… 之前的功夫都白费了啊！

【产品】：不就是生产东西嘛，反正都是生产，我不管，你要给我实现！

【BOSS】：小柯，委屈你了。

【开发】：好吧，那我能问一个问题吗？未来是不是还有可能要生产华为的，联想的？

【产品】：对！很有可能！如果我们生意做大了！

### HeadFirst 核心代码 ###

抽象工厂模式着重点在产品族上，开始撸代码吧~

**父级抽象类**

public abstract class AbstractFactory { 
    
        /** * 创建CPU对象 * @return CPU对象 */
        public abstract AbstractCPU createCpu();
    
        /** * 创建主板对象 * @return 主板对象 */
        public abstract AbstractMotherboard createMainboard();
    }

**子类实现**

public class IntelFactory extends  AbstractFactory{ 
    
        @Override
        public AbstractCPU createCpu() { 
            return new IntelCpu();
        }
    
        @Override
        public AbstractMotherboard createMainboard() { 
            return new IntelMotherboard();
        }
    }
    
    // *************************************************************
    
    public class AMDFactory extends AbstractFactory{ 
        @Override
        public AbstractCPU createCpu() { 
            return new AMDCpu();
        }
    
        @Override
        public AbstractMotherboard createMainboard() { 
            return new AMDMotherboard();
        }
    }

抽象工厂模式的设计思路：

*  AbstractProduct 为一类产品对象声明一个接口
 *  ConcreteProduct 具体对象
 *  AbstractFactory 声明一个创建抽象产品对象的接口
 *  ConcreteFactory 具体的产品族工厂

思路示意图：

![format_png 3][]

### 工厂方法是不是潜伏在抽象工厂中？ ###

没错，抽象工厂的方法经常以工厂方法的方式实现，因为抽象工厂的任务通常是定义一个负责创建一组产品的接口，在这个接口内的每个方法都负责创建一个具体的产品，***而这种某一个具体的产品的实质就是工厂方法模式的实践***

### 什么场景适用 ###

在以下情况可以使用 Abstract Factory 模式：

*  系统要独立于它的产品的创建、组合和表示时
 *  系统要由多个产品系列中的一个来配置时
 *  当你要强调一系列相关的产品对象的设计以便进行联合使用时
 *  当你提供一个产品类库，而只想显示它们的接口而不是实现时

### Code/生活中的实际应用 ###

比如上述的情况，观察代码我们可以发现我们其实是把一个产品族进行了封装，如果这个时候要引入华为系列产品，我们完全不用动任何代码，只需要增加一个类即可，非常符合开闭原则

### UML图 ###

![format_png 4][]

## 遵循的设计原则 ##

**依赖抽象，而不是依赖具体**

*  无论是简单工厂还是工厂方法，亦或是抽象工厂，都是强调解耦，依赖抽象，不依赖具体

## 总结 ##

**相同点：**

*  所有的工厂都是用来封装对象的创建
 *  简单工厂，虽然不是真正的设计模式，但仍不失为一个简单的方法，可以进行解耦
 *  所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合
 *  依赖倒置原则，指导我们避免依赖具体类型，而要尽量依赖抽象
 *  工厂是很有威力的技巧，帮助我们针对抽象编程，而不是具体类编程

**工厂方法：**

*  工厂方法利用继承：把对象的创建委托给子类，子类实现工厂方法来创建对象
 *  工厂方法允许类将实例化延迟到子类实现

**抽象工厂：**

*  抽象工厂使用对象组合：对象的创建被实现在工厂接口所暴露出来的方法中
 *  抽象工厂创建相关的对象家族，而不需要依赖它们的具体类

## 相关代码链接 ##

[GitHub地址][GitHub]

*  兼顾了《HeadFirst》以及《GOF》两本经典书籍中的案例
 *  提供了友好的阅读指导

![format_png 5][]

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC81LzI1LzE3MjRjMTA4ZmU0ZjJjZGI?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC81LzI1LzE3MjRjMTBjNWIwOTJjMjM?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC81LzI1LzE3MjRjMTBmN2FjYmZhMGI?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC81LzI1LzE3MjRjMTExZTMxNDY2YmM?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC81LzI1LzE3MjRjMTE0MjU0NDU2NmE?x-oss-process=image/format,png
[GitHub]: https://github.com/kkzhilu/Kerwin-DesignPattern
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91c2VyLWdvbGQtY2RuLnhpdHUuaW8vMjAyMC81LzI1LzE3MjRjMTE2NWRhMjM4Yjc?x-oss-process=image/format,png