1. 实验结果:
记录并附上不同模型对象(例如:士兵、机器人、骑士)的展示效果截图。
2. 性能分析:
记录并比较抽象工厂模式与直接实例化的性能测试结果,分析它们在不同数量级对象创建时的开销与效益。
2.1 直接实例化
10对象
5000对象
2.2 用抽象工厂模式进行实例化
10对象
5000对象
2.3 测试结果
数量少时(10个对象)
- 直接实例化:由于对象数量较少,直接实例化的开销小,平均执行时间为3ms。
- 抽象工厂模式:抽象工厂模式在创建对象时需要额外的逻辑判断,因此平均执行时间为7ms,高于直接实例化。
数量多时(5000个对象)
- 直接实例化:随着对象数量的增加,直接实例化的开销也线性增加,平均执行时间为1282ms。
- 抽象工厂模式:抽象工厂模式的开销同样线性增加,但由于每次创建对象时都需要进行额外的逻辑判断,因此平均执行时间为331毫秒,比直接实例化多951毫秒。
2.4 开销与效益分析
-
直接实例化:
- 优点:在对象数量较少时,性能开销非常小,适合简单的对象创建场景。
- 缺点:随着对象数量的增加,性能开销线性增加,且难以扩展和维护。
-
抽象工厂模式:
- 优点:提供了良好的扩展性和维护性,适合需要频繁扩展和修改的复杂系统。
- 缺点:在对象数量较少时,性能开销略高于直接实例化;在对象数量较多时,性能开销显著增加,但仍然保持线性增长。
2.5 结论
- 数量少时:直接实例化在性能上略优于抽象工厂模式。
- 数量多时:抽象工厂模式的性能开销显著高于直接实例化,但由于其提供了更好的扩展性和维护性,适合复杂系统。
3. 问题与思考:
3.1 实现过程中遇到的挑战和解决方案
3.1.1 复杂性增加
抽象工厂模式引入了多个接口和类,增加了代码的复杂性。
解决方案
通过良好的代码组织和注释,确保代码的可读性和可维护性。
3.1.2 扩展性问题
随着系统的扩展,可能需要频繁修改工厂类和产品类,增加了维护成本。
解决方案
通过设计良好的接口和抽象类,确保系统的可扩展性,减少对现有代码的修改。
3.2 使用抽象工厂模式解决实际问题。
抽象工厂模式适用于以下实际问题:
-
产品族的创建:
- 问题:需要创建一组相关或依赖的产品族,例如不同风格的游戏对象(现代、科幻、中世纪)。
- 解决方案:使用抽象工厂模式,定义一个抽象工厂接口,每个具体工厂负责创建一个产品族。
-
系统独立于产品的创建:
- 问题:系统需要独立于产品的具体实现,以便在运行时动态切换产品。
- 解决方案:通过抽象工厂模式,系统可以在运行时选择不同的工厂,从而创建不同的产品。
-
避免紧耦合:
- 问题:系统中各个模块之间存在紧耦合,难以扩展和维护。
- 解决方案:使用抽象工厂模式,将产品的创建逻辑与使用逻辑分离,降低模块之间的耦合度。
3.3 工厂模式和抽象工厂模式的异同
相同之处
- 创建对象:工厂模式和抽象工厂模式都用于创建对象,将对象的实例化过程从客户端代码中解耦。
- 抽象接口:两者都使用抽象接口来定义对象的创建方法,客户端通过接口与具体工厂进行交互。
- 封装变化:两者都通过封装对象的创建过程,使得客户端代码与具体对象的创建细节分离,从而提高代码的可维护性和扩展性。
不同之处
- 作用范围:工厂模式关注的是创建单个对象,它通过一个具体工厂类来创建一个具体产品类的实例。抽象工厂模式关注的是创建一系列相关的产品对象,它通过一个抽象工厂类来创建一组具有相同主题的产品对象。
- 对象族:工厂模式创建的对象属于同一产品等级结构中的一员。抽象工厂模式创建的对象属于多个产品等级结构中的一组相关产品。
- 结构复杂度:工厂模式相对简单,通常只涉及一个抽象产品和一个具体产品。抽象工厂模式相对复杂,涉及多个抽象产品和多个具体产品,需要定义更多的接口和类。
- 可扩展性:工厂模式在需要添加新的具体产品时,只需扩展具体工厂类和具体产品类。抽象工厂模式在需要添加新的产品族时,需要扩展抽象工厂类和所有相关的具体工厂类和具体产品类。
工厂模式的适用场景
- 创建复杂对象:当对象的创建过程复杂或者依赖多个其他对象时,使用工厂模式可以简化对象的创建过程。
- 需要解耦:当客户端不应该知道具体的产品类时,工厂模式可以将对象的创建和使用分离,提高系统的灵活性。
- 支持多种产品:当需要支持多种产品,并且这些产品之间存在共同的接口时,工厂模式可以提供统一的创建接口。
- 需要扩展系统:当系统需要在未来扩展以支持更多产品时,工厂模式可以方便地添加新的产品类而不影响现有代码。
抽象工厂模式的适用的场景
产品族的创建:当系统需要创建一组相关或相互依赖的产品时,使用抽象工厂模式可以确保产品的一致性和完整性。
需要解耦的系统:当需要将产品的创建与使用分离,减少系统之间的耦合度时,抽象工厂模式是一个理想的选择。
需要支持多个产品变体:在需要支持不同变体的情况下,例如不同地区的怪物、不同类型的用户界面组件等,抽象工厂模式可以有效管理这些变体。
需要扩展产品类型:当系统需要频繁扩展新产品类型时,抽象工厂模式提供了良好的扩展机制,符合开闭原则。
框架设计:在设计框架或库时,抽象工厂模式可以为用户提供灵活的产品创建接口,用户可以根据需要实现具体的工厂类。
3.4 在实际游戏开发中选择合适的设计模式。
-
系统复杂度:
- 简单系统:选择工厂模式,减少复杂性,提高性能。
- 复杂系统:选择抽象工厂模式,提高系统的扩展性和维护性。
-
扩展需求:
- 频繁扩展:选择抽象工厂模式,便于添加新的产品族。
- 较少扩展:选择工厂模式,简化系统结构。
-
性能要求:
- 高性能要求:选择工厂模式,减少创建对象的开销。
- 性能要求较低:选择抽象工厂模式,提高系统的灵活性。
-
代码可维护性:
- 高可维护性要求:选择抽象工厂模式,降低模块之间的耦合度。
- 低可维护性要求:选择工厂模式,简化代码结构。
拓展
添加
在此处切换风格
效果