一、概念
工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。从而使得系统更加灵活。客户端可以通过调用工厂方法来创建所需的产品，而不必关心具体的实现细节。这种模式符合开放-封闭原则，对扩展开放、对修改关闭。
二、与简单工厂模式的区别
| 特点 | 简单工厂 | 工厂方法模式 |
|---|---|---|
| 定义 | 由一个工厂类负责创建所有产品对象。 | 定义一个用于创建对象的接口，让子类决定实例化哪一个类。 |
| 角色数量 | 只有一个工厂类，可能会有多个产品类。 | 有多个具体工厂类，每个具体工厂负责创建一种产品。 |
| 扩展性 | 添加新产品时需要修改简单工厂类，违反开闭原则。 | 添加新产品只需增加新的具体工厂和产品类，不需要修改现有代码。 |
| 客户端代码 | 客户端直接依赖于简单工厂类，通常需要知道具体的产品类型。 | 客户端只依赖于抽象工厂类，不需要知道具体的工厂实现。 |
| 复杂度 | 实现较为简单，适合产品较少的情况。 | 实现较为复杂，但适合需要扩展的系统。 |
如图我们在简单工厂模式中计算器的例子，如果我在新增一个计算方法√、或者平方、立方那么我将直接改造工厂类，如果新增的许多计算方法，那么我们简单工厂中将会有大量的代码逻辑，这违反了开闭原则的。
在比如我们想买一辆比亚迪电车，最初比亚迪比较小，只有一个工厂，我们所有的车都在这个工厂里制造没问题，可随着比亚迪的发展越来越牛逼，不仅有低端车更是有几百万的高端车，这时候一个工厂远远满足不了产能的需求，而且如果这个工厂gg了，所有的车都制造不出来了，这是不被允许的，于是领导小手一拍建立了多个不同车型的制造工厂，比如王朝系列，海洋系列工厂，分别制造不同的车型，这就是从简单工厂模式->工厂方法模式的进阶。
优点
- 遵循开闭原则：可以通过添加新的具体工厂和产品类来扩展产品，而无需修改现有代码，增强了系统的可扩展性。提高代码灵活性：
- 客户端只依赖于抽象工厂接口，具体产品的创建逻辑在子类中实现，客户端无需了解具体实现。
- 封装对象创建：将对象的创建过程封装在工厂子类中，客户端代码更加简洁，关注于使用而不是创建。
- 减少耦合将产品的实例化与使用分离，不需要知道每个具体产品的类名，降低了系统的耦合度。
缺点
- 增加代码复杂性：引入多个工厂和产品类，代码结构较为复杂，对于简单需求可能显得过于臃肿。
- 类数量增多：每增加一种新产品都需要相应地增加一个具体工厂类，这可能导致系统中类的数量增加，管理起来较为繁琐。
- 学习成本：对于不熟悉设计模式的开发者来说，理解和正确应用工厂方法模式需要一定时间和经验。
三、适用场景
当一个类不知道它所必须创建的对象的类时。
当一个类希望由其子类来指定生成对象时。
当将创建对象的职责委托给多个帮助子类中的某一个，并希望将哪一个子类是代理者这一信息局部化时。
通过合理使用工厂方法模式，可以提升系统的灵活性和可维护性，但需要权衡其复杂性和实际需求。
四、实例分析
接着上述计算器的例子，我们继续优化。
对于加减乘除这种很基础的操作我们可以单独封装为基础运算操作类，对于根号运算，幂等运算可以定义为高级运算操作类，这样无论我添加多少额外的运算方法，都不会影响基础的运算。
先定义一个用于创建对象的接口，定义了一个创建 Operation对象的方法 createOperation()。这个方法没有具体的实现，而是留给子类来决定如何创建具体的对象。
增加两个高级运算类 指数运算、对数运算。
具体工厂类 FactoryBasic 和 FactoryAdvanced 继承自 IFactory，并实现了 createOperation() 方法。在这些子类中，具体的实例化逻辑被定义为返回对应运算方法的运算对象。
对比与简单工厂方法中的OperationFactory，新的OperationFactory类已经不存在运算子类实例化的
代码了。也就是说，在这个代码里，全部是接口与具体工厂类，并不存在具体的实现，与原来的OperationFactory类对比，实例化的过程延迟到了工厂子类中。
