【设计模式笔记11】：简单工厂模式优缺分析

核心角色 : 简单工厂模式的核心是工厂类 (Factory) 。在没有引入工厂类之前，客户端通常会使用 new 关键字来直接创建所需的产品对象，这导致客户端代码与具体产品类紧密耦合。
职责转移 : 在引入工厂类之后，客户端的职责发生了转移。它不再负责创建产品，而是通过调用工厂类提供的静态工厂方法来获取产品。客户端只需传入约定的参数，工厂类就会根据这些参数创建并返回不同的产品对象。
简化调用 : 在客户端代码中，我们只需通过 类名.静态方法() 的方式调用工厂方法，即可得到一个抽象产品类型的实例，整个过程对客户端来说非常简单。

实现了创建与使用的分离
- 工厂类是整个模式的关键。它含有所有必要的判断逻辑（通常是 if/else 或 switch 语句），可以决定在什么时候创建哪一个产品类的实例。
- 客户端可以免除直接创建产品对象的责任，角色从"生产者"转变为纯粹的"消费者"。这种职责的分离让系统结构更加清晰。
客户端代码简洁，降低使用难度
- 客户端无需知道所要创建的具体产品的类名，只需要知道这些产品所对应的参数即可（例如，一个字符串）。
- 这可以减少使用者的记忆量和认知负担，使得代码的调用方更加简单直观。

工厂类职责过重，存在单点故障风险
- 工厂类集中了所有产品的创建逻辑，所有的创建请求都由这一个类来处理。一旦这个工厂类不能正常工作（例如出现Bug），整个系统的对象创建过程都会受到影响。
增加了系统的复杂性
- 引入简单工厂模式会增加系统中类的数量（至少增加一个工厂类和多个产品类），对于非常简单的应用场景，这反而会增加系统的复杂度和理解难度。
系统扩展困难，违反开闭原则
- 这是简单工厂模式最主要的缺点 。一旦系统中需要添加新产品，就不得不修改工厂类的判断逻辑 ，即在 if/else 或 switch 语句中增加新的分支。
- 这种做法违反了"开闭原则"（对扩展开放，对修改关闭）。随着产品种类的增多，工厂类的逻辑会变得越来越庞大和复杂，不利于系统的扩展和维护。
无法形成基于继承的等级结构
- 简单工厂模式通常使用静态工厂方法。由于静态方法无法被子类继承和重写（Override），这导致工厂角色本身无法形成一个基于继承的等级结构。你无法通过创建一个工厂子类来改变创建产品的行为。