🌈 个人主页：danci_
🔥 系列专栏：《设计模式》
💪🏻 制定明确可量化的目标，坚持默默的做事。
🚀 转载自：++设计模式深度解析：工厂方法模式与抽象工厂模式的深度对比++ 已被《松山湖开发者村综合服务平台》收录
设计模式深度解析：工厂方法模式与抽象工厂模式的深度对比
文章目录
- 一、定义🌐
- 二、结构图🔍
- <code>三、易混场景💔<code>
- [五、总结 💖](#五、总结 💖)
一、定义🌐
工厂方法模式
|----------------------------------------|
| 定义一个用于创建对象的接口，将具体实例化对象的工作推迟到子类中完成。 |
作用
|--------------------------------------------------------|
| 当系统需要引入新的产品类型时，只需要增加相应的工厂子类，而不需要修改原有的系统代码，从而实现了"开闭原则"。 |
如何封装对象的创建过程
在工厂方法模式中，对象的创建过程被封装在工厂类的工厂方法中。具体来说，这个过程包括以下几个步骤：👇
- 定义抽象产品接口：
首先，需要定义一个抽象产品接口，该接口描述了所有具体产品类应该具有的方法。
- 定义抽象工厂类：
然后，定义一个抽象工厂类，该类声明了一个工厂方法，用于创建抽象产品接口的对象。这个工厂方法通常被声明为抽象方法，以便子类可以实现它。
- 实现具体产品类：
接下来，根据抽象产品接口定义具体的产品类。这些类实现了抽象产品接口中声明的方法，并提供了具体的产品实现。
- 实现具体工厂类：
然后，创建具体工厂类，该类继承自抽象工厂类，并实现工厂方法。在工厂方法中，具体工厂类根据需要创建并返回相应的具体产品对象。
通过这种方式，工厂方法模式封装了对象的创建过程。客户端代码只需要知道抽象产品接口和抽象工厂类，而无需关心具体产品类的实现和对象的创建过程。这有助于降低代码的耦合度，提高系统的可扩展性和可维护性。同时，由于具体产品的创建逻辑是由具体工厂类来实现的，因此也增加了系统的灵活性，使得系统可以更容易地引入新的产品类型。
抽象工厂模式
|--------------------------------------------------------|
| 提供了一个创建一系列相关或相互依赖对象的接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。 |
作用
|---------------------------------------------|
| 通过抽象化对象的创建过程，实现高内聚低耦合的设计原则，增强系统的可扩展性和可维护性。。 |
如何封装对象的创建过程
在抽象工厂模式中，每个工厂都能够创建一系列相互关联或依赖的对象，而客户端代码则通过抽象接口与这些工厂进行交互，从而无需了解具体对象的创建逻辑。抽象工厂模式通过以下几个关键步骤来封装对象的创建过程：👇
- 定义抽象产品接口：
首先，为每种类型的产品定义一个抽象接口。这些接口将规定所有具体产品类必须实现的方法。
- 定义抽象工厂接口：
接下来，定义一个抽象工厂接口，该接口将声明一组创建抽象产品的方法。这些方法通常对应于步骤1中定义的抽象产品接口。
- 实现具体产品类：
根据步骤1中定义的抽象产品接口，创建具体的产品类。这些类将实现抽象产品接口中声明的方法，并提供具体的产品实现。
- 实现具体工厂类：
创建具体工厂类，该类将实现抽象工厂接口。在具体工厂类中，实现抽象工厂接口中声明的方法，以便它们能够创建和返回相应的具体产品对象。
- 客户端代码使用：
在客户端代码中，通过创建具体工厂类的对象并使用它来创建产品对象。客户端代码仅依赖于抽象产品接口和抽象工厂接口，因此与具体产品类和具体工厂类的实现细节解耦。
模式对比
为便于对比理解，总结如下图所示：
工厂模式 定义了一个用于创建对象的接口，让子类决定实例化哪一个类。它将一个类的实例化延迟到子类进行，这样可以将对象的创建与使用分离，使代码更加灵活和可维护。在工厂模式中，通常会有一个具体的工厂类负责创建某一类产品，客户端直接调用工厂类的方法来获取所需的对象。
抽象工厂模式 则提供了一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。这个模式允许客户端在不指定具体产品类的情况下创建多个产品族中的产品对象。抽象工厂模式是所有形态的工厂模式中最为抽象和最具有一般性的一种形态。在抽象工厂模式中，工厂类不再仅仅负责创建单一产品，而是负责创建一组具有相同主题或相互依赖的产品对象。这意味着抽象工厂模式通常涉及多个抽象产品和多个具体产品，需要定义更多的接口和类。
进一步来说，工厂方法模式与抽象工厂模式的区别主要体现在创建对象的范围和复杂度上。工厂模式主要关注单一产品等级的创建，而抽象工厂模式则强调多个产品族中相关对象的创建。从结构上看，工厂模式相对简单，而抽象工厂模式则更为复杂，涉及更多的接口和类定义。
二、结构图🔍
参与者👇
- 工厂方法模式：
**产品（Product）:**定义工厂方法所创建的对象的接口。所有被创建的对象都是某个具体产品的实例。
**具体产品（Concrete Product）:**实现产品接口的具体类。工厂方法模式所创建的每个对象都是某个具体产品类的实例。
创建者（Creator）: 声明工厂方法，该方法返回一个产品类型的对象。创建者可能提供工厂方法的默认实现，它返回一个默认的具体产品对象。
具体创建者（Concrete Creator）: 重写工厂方法以返回一个具体产品实例。每个具体创建者通常与一个特定的具体产品一一对应。
工厂方法模式通过抽象工厂类和具体工厂类的协作，实现了对象的延迟实例化，降低了系统的耦合度，提高了系统的可维护性和扩展性。同时，它还利用了多态性，使得代码更加灵活和可重用。
- 抽象工厂模式：
**抽象工厂（Abstract Factory）：**它声明了一组用于创建一系列产品的方法，每个方法都对应一个产品等级。抽象工厂可以看作是一个工厂的工厂，或者是一系列工厂的抽象。在抽象工厂中，每个方法对应一种产品，实现了对产品的集中管理。客户端使用抽象工厂来获取产品时，无需关心具体实现，只需通过调用相应的方法即可获取到产品。
**具体工厂（Concrete Factory）：**它实现了抽象工厂中声明的创建产品的方法，以生产具有共同主题的具体产品。每个具体工厂负责生成一个产品族中的所有产品，这些产品之间具有一定的关联性或依赖性。当客户端需要某个产品族中的产品时，只需使用相应的具体工厂即可。
**抽象产品（Abstract Product）：**它是定义产品的接口，描述了所有产品所共有的特性或方法。每个抽象产品对应一个产品等级结构，即同一类产品的不同实现方式。
具体产品（Concrete Product）： 它实现了抽象产品中定义的接口，提供了具体的产品实现。每个具体产品都属于一个产品族，与该产品族中的其他产品具有一定的关联性或依赖性。
抽象工厂模式适用于需要创建一系列相互关联或相互依赖的产品的场景。它通过将具体工厂的创建过程抽象化，使得客户端可以根据需要灵活地选择不同的产品族进行创建，从而实现了代码的解耦和模块化。然而，抽象工厂模式的缺点是当需要增加新的产品族时，需要修改抽象工厂的接口以及所有具体工厂的实现，这可能会带来较大的改动和维护成本。因此，在使用抽象工厂模式时需要权衡其优点和缺点，根据具体的业务需求和系统规模进行选择。
适用场景
三、易混场景💔
场景
|---------------------------------------------------------------------|
| 假设我们正在开发一个游戏，游戏中有多种类型的角色，每种角色都有不同的武器和技能。我们需要设计一个系统来创建和管理这些角色、武器和技能。 |
在这个场景中，我们可以考虑使用工厂方法模式或抽象工厂模式来创建角色、武器和技能对象。然而，这两种模式的选择和使用方式可能会引起混淆。
工厂方法模式
|-------------------------------------------------------------------------------------------------------------------------------------------------|
| 如果我们选择使用工厂方法模式，我们可以定义一个抽象的角色工厂类，它声明了一个创建角色的工厂方法。然后，我们可以为每种具体的角色类型创建一个具体的角色工厂类，这些工厂类实现了抽象角色工厂类中声明的工厂方法，用于创建具体类型的角色对象。同样地，我们也可以为武器和技能定义类似的工厂类和方法。 |
在这种情况下，如果我们需要创建一个具有特定武器和技能的角色对象，我们可能需要分别调用角色工厂、武器工厂和技能工厂的方法。这可能会导致代码中的耦合度增加，因为客户端代码需要知道如何组合使用这些工厂方法来创建完整的角色对象。
抽象工厂模式
|------------------------------------------------------------------------------------------------------------------------------------|
| 如果我们选择使用抽象工厂模式，我们可以定义一个抽象的工厂接口，该接口声明了一组创建角色、武器和技能对象的工厂方法。然后，我们可以为每种具体的角色类型创建一个具体的工厂类，这些工厂类实现了抽象工厂接口中声明的所有工厂方法，用于创建特定类型的角色、武器和技能对象。 |
在这种情况下，客户端代码只需要知道如何使用抽象工厂接口即可创建完整的角色对象，而无需关心具体工厂类的实现细节。这有助于降低代码中的耦合度，提高系统的灵活性和可扩展性。然而，当需要添加新的角色类型或新的产品族时，可能需要修改抽象工厂接口和现有的具体工厂类，这可能会带来一些维护成本。
易混淆之处
在这个场景中，工厂方法模式和抽象工厂模式的易混淆之处在于它们都涉及创建多种类型的对象。然而，++工厂方法模式侧重于通过继承来实现对象的创建逻辑的封装和扩展++，而++抽象工厂模式则侧重于通过组合来实现一系列相互关联或相互依赖的产品的创建逻辑的封装和扩展++。因此，在选择使用这两种模式时，需要根据具体的系统需求和设计目标来进行权衡和决策。
注： 在实际应用中，这两种模式并不是互斥的，而是可以相互结合使用的。例如，我们可以在抽象工厂模式中使用工厂方法来创建具体的产品对象，从而实现更灵活和可扩展的系统设计。
五、总结 💖
工厂方法模式
- 封装性：
🌈 工厂模式通过专门的工厂类来创建其他类的实例，隐藏了对象创建的具体逻辑，客户端只需要知道产品的抽象接口和工厂类提供的创建方法。
- 解耦：
🌈 工厂模式减少了客户端与具体产品类之间的依赖，客户端通过工厂接口与工厂类交互，无需了解具体实现细节。
- 单一职责：
🌈 每个工厂类通常只负责创建一种或一类产品，符合单一职责原则。
- 扩展性：
🌈 当需要添加新产品时，只需增加相应的具体产品类和对应的工厂类，而无需修改客户端代码。
工厂模式最佳实践和使用场景
-
🌈 当需要创建的对象具有复杂的初始化逻辑或依赖于外部资源时，使用工厂模式可以封装这些复杂性。
-
🌈 当系统中存在多个类似的产品，且这些产品的创建逻辑可能会变化时，使用工厂模式可以提高系统的灵活性和可维护性。
-
🌈 当希望将对象的创建与使用分离，以便在不修改客户端代码的情况下更换产品实现时，使用工厂模式可以实现这一目标。
抽象工厂模式关键点
- 产品族：
🚀 抽象工厂模式强调一系列相互关联或相互依赖的产品对象（产品族）的创建，而不仅仅是单个产品的创建。
- 一致性：
🚀 客户端通过抽象工厂接口获取一系列产品对象，确保这些对象在逻辑上是一致的、相互兼容的。
- 封装性：
🚀 抽象工厂模式封装了具体产品族的创建逻辑，客户端只需要与抽象工厂接口交互。
- 扩展性：
🚀 当需要添加新的产品族时，只需增加相应的具体工厂类，而无需修改现有代码（遵循开闭原则）。
抽象工厂模式最佳实践和使用场景
-
🚀 当系统需要处理多个产品族，并且每个产品族包含多个相互关联的产品时，使用抽象工厂模式可以方便地创建和管理这些产品族
-
🚀 当希望确保客户端使用的产品对象来自同一个产品族，以保持逻辑上的一致性时，使用抽象工厂模式可以实现这一目标。
-
🚀 当产品的创建逻辑可能会因为不同的平台、配置或环境而有所不同时，使用抽象工厂模式可以方便地切换不同的产品族实现。
根据项目需求选用正确的模式的建议
- 分析需求：
✨ 首先明确项目中需要创建的对象类型以及它们之间的关系。如果只需要创建单一类型的对象，且对象的创建逻辑相对简单，那么工厂模式可能是更好的选择。如果需要创建多个相互关联的对象（产品族），则考虑使用抽象工厂模式。
- 考虑扩展性：
✨ 评估未来可能的产品变化。如果预计会有新的产品类型或产品族加入，那么选择更具扩展性的模式（如抽象工厂模式）可能更为合适。
- 遵循设计原则：
✨ 尽量遵循面向对象设计原则，如单一职责原则、开闭原则等。这些原则可以帮助你做出更合理的模式选择。
- 代码简洁性：
✨ 在满足功能需求的前提下，尽量选择使代码更简洁、易于理解和维护的模式。过度设计可能会增加系统的复杂性和维护成本。
应用考量
- 系统的复杂度：
🌟 如果系统相对简单，产品种类较少且不太可能发生变化，那么简单工厂模式可能是更好的选择。如果系统复杂，存在多个产品族且产品族之间可能存在较大差异，那么抽象工厂模式可能更合适。
- 可扩展性需求：
🌟 如果预计未来需要频繁添加新产品或新产品族，那么抽象工厂模式可能更具扩展性。因为抽象工厂模式可以通过添加新的具体工厂类来引入新产品族，而无需修改现有代码。而简单工厂模式可能需要修改工厂类以适应新产品的创建。
- 设计原则：
🌟 尽量遵循面向对象设计原则，如单一职责原则、开闭原则等。这些原则可以帮助你做出更合理的模式选择。例如，如果希望遵循开闭原则，那么抽象工厂模式可能更合适，因为它允许在不修改现有代码的情况下扩展系统。
- 代码简洁性：
🌟 在满足功能需求的前提下，尽量选择使代码更简洁、易于理解和维护的模式。过度设计可能会增加系统的复杂性和维护成本。因此，在选择设计模式时，需要权衡其带来的好处和可能增加的复杂性。
❤️ 选择简单工厂模式还是抽象工厂模式应根据具体项目的需求、复杂度和可扩展性要求来决定。在实际应用中，可以先从简单工厂模式开始，随着项目的发展和需求的变化，再考虑是否升级到抽象工厂模式或其他更复杂的模式。