工厂方法模式与抽象工厂模式的深度对比

工厂方法模式与抽象工厂模式的深度对比

引用

CSDN

1.

https://blog.csdn.net/danci_bto/article/details/137197454

工厂方法模式和抽象工厂模式是两种常用的设计模式，它们都用于创建对象，但侧重点和使用场景有所不同。本文将通过对比这两种模式，帮助读者更好地理解它们的特点和适用场景。

一、定义

工厂方法模式

定义一个用于创建对象的接口，将具体实例化对象的工作推迟到子类中完成。

作用：当系统需要引入新的产品类型时，只需要增加相应的工厂子类，而不需要修改原有的系统代码，从而实现了“开闭原则”。

如何封装对象的创建过程：

1. 定义抽象产品接口：描述所有具体产品类应该具有的方法。
2. 定义抽象工厂类：声明一个工厂方法，用于创建抽象产品接口的对象。
3. 实现具体产品类：根据抽象产品接口定义具体的产品类。
4. 实现具体工厂类：创建具体工厂类，该类继承自抽象工厂类，并实现工厂方法。

抽象工厂模式

提供了一个创建一系列相关或相互依赖对象的接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

作用：通过抽象化对象的创建过程，实现高内聚低耦合的设计原则，增强系统的可扩展性和可维护性。

如何封装对象的创建过程：

1. 定义抽象产品接口：为每种类型的产品定义一个抽象接口。
2. 定义抽象工厂接口：声明一组创建抽象产品的方法。
3. 实现具体产品类：根据抽象产品接口，创建具体的产品类。
4. 实现具体工厂类：创建具体工厂类，实现抽象工厂接口。
5. 客户端代码使用：通过抽象产品接口和抽象工厂接口与具体产品类和具体工厂类解耦。

二、结构图

参与者

工厂方法模式

• 产品（Product）：定义工厂方法所创建的对象的接口。
• 具体产品（Concrete Product）：实现产品接口的具体类。
• 创建者（Creator）：声明工厂方法，返回一个产品类型的对象。
• 具体创建者（Concrete Creator）：重写工厂方法以返回一个具体产品实例。

抽象工厂模式

• 抽象工厂（Abstract Factory）：声明一组用于创建一系列产品的方法。
• 具体工厂（Concrete Factory）：实现抽象工厂中声明的创建产品的方法。
• 抽象产品（Abstract Product）：定义产品的接口。
• 具体产品（Concrete Product）：实现抽象产品中定义的接口。

适用场景

工厂方法模式适用于需要创建单一类型对象的场景，而抽象工厂模式适用于需要创建一系列相关或相互依赖对象的场景。

三、易混场景

场景

假设我们正在开发一个游戏，游戏中有多种类型的角色，每种角色都有不同的武器和技能。我们需要设计一个系统来创建和管理这些角色、武器和技能。

工厂方法模式

可以定义一个抽象的角色工厂类，然后为每种具体的角色类型创建一个具体的角色工厂类。同样地，可以为武器和技能定义类似的工厂类和方法。

抽象工厂模式

可以定义一个抽象的工厂接口，该接口声明了一组创建角色、武器和技能对象的工厂方法。然后，为每种具体的角色类型创建一个具体的工厂类。

易混淆之处

工厂方法模式侧重于通过继承来实现对象的创建逻辑的封装和扩展，而抽象工厂模式则侧重于通过组合来实现一系列相互关联或相互依赖的产品的创建逻辑的封装和扩展。

五、总结

工厂方法模式

• 封装性：通过专门的工厂类来创建其他类的实例，隐藏了对象创建的具体逻辑。
• 解耦：减少了客户端与具体产品类之间的依赖。
• 单一职责：每个工厂类通常只负责创建一种或一类产品。
• 扩展性：当需要添加新产品时，只需增加相应的具体产品类和对应的工厂类。

工厂模式最佳实践和使用场景

1. 当需要创建的对象具有复杂的初始化逻辑或依赖于外部资源时。
2. 当系统中存在多个类似的产品，且这些产品的创建逻辑可能会变化时。
3. 当希望将对象的创建与使用分离，以便在不修改客户端代码的情况下更换产品实现时。

抽象工厂模式关键点

1. 产品族：强调一系列相互关联或相互依赖的产品对象的创建。
2. 一致性：确保客户端获取的产品对象在逻辑上是一致的、相互兼容的。
3. 封装性：封装了具体产品族的创建逻辑。
4. 扩展性：当需要添加新的产品族时，只需增加相应的具体工厂类。

抽象工厂模式最佳实践和使用场景

1. 当系统需要处理多个产品族，并且每个产品族包含多个相互关联的产品时。
2. 当希望确保客户端使用的产品对象来自同一个产品族，以保持逻辑上的一致性时。
3. 当产品的创建逻辑可能会因为不同的平台、配置或环境而有所不同时。

根据项目需求选用正确的模式的建议

1. 分析需求：明确项目中需要创建的对象类型以及它们之间的关系。
2. 考虑扩展性：评估未来可能的产品变化。
3. 遵循设计原则：尽量遵循面向对象设计原则。
4. 代码简洁性：在满足功能需求的前提下，选择使代码更简洁、易于理解和维护的模式。

应用考量

1. 系统的复杂度：如果系统相对简单，产品种类较少且不太可能发生变化，那么简单工厂模式可能是更好的选择。
2. 可扩展性需求：如果预计未来需要频繁添加新产品或新产品族，那么抽象工厂模式可能更具扩展性。
3. 设计原则：尽量遵循面向对象设计原则。
4. 代码简洁性：在满足功能需求的前提下，尽量选择使代码更简洁、易于理解和维护的模式。

❤️ 选择简单工厂模式还是抽象工厂模式应根据具体项目的需求、复杂度和可扩展性要求来决定。在实际应用中，可以先从简单工厂模式开始，随着项目的发展和需求的变化，再考虑是否升级到抽象工厂模式或其他更复杂的模式。

本文原文来自CSDN