自学内容网 自学内容网

工厂模式和抽象工厂模式的实验报告

1. 实验结果:

记录并附上不同模型对象(例如:士兵、机器人、骑士)的展示效果截图。


2. 性能分析:

记录并比较抽象工厂模式与直接实例化的性能测试结果,分析它们在不同数量级对象创建时的开销与效益。

2.1 直接实例化

10对象

5000对象

2.2 用抽象工厂模式进行实例化

10对象

5000对象

2.3 测试结果

数量少时(10个对象)

  • 直接实例化:由于对象数量较少,直接实例化的开销小,平均执行时间为3ms。
  • 抽象工厂模式:抽象工厂模式在创建对象时需要额外的逻辑判断,因此平均执行时间为7ms,高于直接实例化。

数量多时(5000个对象)

  • 直接实例化:随着对象数量的增加,直接实例化的开销也线性增加,平均执行时间为1282ms。
  • 抽象工厂模式:抽象工厂模式的开销同样线性增加,但由于每次创建对象时都需要进行额外的逻辑判断,因此平均执行时间为331毫秒,比直接实例化多951毫秒。

2.4 开销与效益分析

  1. 直接实例化

    • 优点:在对象数量较少时,性能开销非常小,适合简单的对象创建场景。
    • 缺点:随着对象数量的增加,性能开销线性增加,且难以扩展和维护。
  2. 抽象工厂模式

    • 优点:提供了良好的扩展性和维护性,适合需要频繁扩展和修改的复杂系统。
    • 缺点:在对象数量较少时,性能开销略高于直接实例化;在对象数量较多时,性能开销显著增加,但仍然保持线性增长。

2.5 结论

  • 数量少时:直接实例化在性能上略优于抽象工厂模式。
  • 数量多时:抽象工厂模式的性能开销显著高于直接实例化,但由于其提供了更好的扩展性和维护性,适合复杂系统。


3. 问题与思考:

3.1 实现过程中遇到的挑战和解决方案

3.1.1 复杂性增加

抽象工厂模式引入了多个接口和类,增加了代码的复杂性。

 解决方案

通过良好的代码组织和注释,确保代码的可读性和可维护性。

3.1.2 扩展性问题

随着系统的扩展,可能需要频繁修改工厂类和产品类,增加了维护成本。

 解决方案

通过设计良好的接口和抽象类,确保系统的可扩展性,减少对现有代码的修改。

3.2 使用抽象工厂模式解决实际问题。

抽象工厂模式适用于以下实际问题:

  • 产品族的创建

    • 问题:需要创建一组相关或依赖的产品族,例如不同风格的游戏对象(现代、科幻、中世纪)。
    • 解决方案:使用抽象工厂模式,定义一个抽象工厂接口,每个具体工厂负责创建一个产品族。
  • 系统独立于产品的创建

    • 问题:系统需要独立于产品的具体实现,以便在运行时动态切换产品。
    • 解决方案:通过抽象工厂模式,系统可以在运行时选择不同的工厂,从而创建不同的产品。
  • 避免紧耦合

    • 问题:系统中各个模块之间存在紧耦合,难以扩展和维护。
    • 解决方案:使用抽象工厂模式,将产品的创建逻辑与使用逻辑分离,降低模块之间的耦合度。


3.3 工厂模式和抽象工厂模式的异同

相同之处

  1. 创建对象:工厂模式和抽象工厂模式都用于创建对象,将对象的实例化过程从客户端代码中解耦。
  2. 抽象接口:两者都使用抽象接口来定义对象的创建方法,客户端通过接口与具体工厂进行交互。
  3. 封装变化:两者都通过封装对象的创建过程,使得客户端代码与具体对象的创建细节分离,从而提高代码的可维护性和扩展性。

不同之处

  1. 作用范围:工厂模式关注的是创建单个对象,它通过一个具体工厂类来创建一个具体产品类的实例。抽象工厂模式关注的是创建一系列相关的产品对象,它通过一个抽象工厂类来创建一组具有相同主题的产品对象。
  2. 对象族:工厂模式创建的对象属于同一产品等级结构中的一员。抽象工厂模式创建的对象属于多个产品等级结构中的一组相关产品。
  3. 结构复杂度:工厂模式相对简单,通常只涉及一个抽象产品和一个具体产品。抽象工厂模式相对复杂,涉及多个抽象产品和多个具体产品,需要定义更多的接口和类。
  4. 可扩展性:工厂模式在需要添加新的具体产品时,只需扩展具体工厂类和具体产品类。抽象工厂模式在需要添加新的产品族时,需要扩展抽象工厂类和所有相关的具体工厂类和具体产品类

工厂模式的适用场景

  1. 创建复杂对象:当对象的创建过程复杂或者依赖多个其他对象时,使用工厂模式可以简化对象的创建过程。
  2. 需要解耦:当客户端不应该知道具体的产品类时,工厂模式可以将对象的创建和使用分离,提高系统的灵活性。
  3. 支持多种产品:当需要支持多种产品,并且这些产品之间存在共同的接口时,工厂模式可以提供统一的创建接口。
  4. 需要扩展系统:当系统需要在未来扩展以支持更多产品时,工厂模式可以方便地添加新的产品类而不影响现有代码。

抽象工厂模式的适用的场景

产品族的创建:当系统需要创建一组相关或相互依赖的产品时,使用抽象工厂模式可以确保产品的一致性和完整性。

需要解耦的系统:当需要将产品的创建与使用分离,减少系统之间的耦合度时,抽象工厂模式是一个理想的选择。

需要支持多个产品变体:在需要支持不同变体的情况下,例如不同地区的怪物、不同类型的用户界面组件等,抽象工厂模式可以有效管理这些变体。

需要扩展产品类型:当系统需要频繁扩展新产品类型时,抽象工厂模式提供了良好的扩展机制,符合开闭原则。

框架设计:在设计框架或库时,抽象工厂模式可以为用户提供灵活的产品创建接口,用户可以根据需要实现具体的工厂类。

3.4 在实际游戏开发中选择合适的设计模式。

  1. 系统复杂度

    • 简单系统:选择工厂模式,减少复杂性,提高性能。
    • 复杂系统:选择抽象工厂模式,提高系统的扩展性和维护性。
  2. 扩展需求

    • 频繁扩展:选择抽象工厂模式,便于添加新的产品族。
    • 较少扩展:选择工厂模式,简化系统结构。
  3. 性能要求

    • 高性能要求:选择工厂模式,减少创建对象的开销。
    • 性能要求较低:选择抽象工厂模式,提高系统的灵活性。
  4. 代码可维护性

    • 高可维护性要求:选择抽象工厂模式,降低模块之间的耦合度。
    • 低可维护性要求:选择工厂模式,简化代码结构。


原文地址:https://blog.csdn.net/m0_74289471/article/details/142482841

免责声明:本站文章内容转载自网络资源,如本站内容侵犯了原著者的合法权益,可联系本站删除。更多内容请关注自学内容网(zxcms.com)!