创建型设计模式之原型模式-CSDN博客

本文链接：https://blog.csdn.net/WDaMu/article/details/150503362

一、原型模式概述

定义：原型模式是一种创建型设计模式，其核心目标是更优雅地实现对象的拷贝，通过让对象实现克隆接口，以达到在不依赖具体类的情况下任意复制对象的目的。

就像复印机复印文件一样，我们有一个原始的“原型”对象，通过克隆操作可以快速得到与该原型具有相同属性的新对象，而无需重新进行复杂的初始化过程。

二、应用场景案例：RTS 游戏兵种生成

场景描述：在即时战略（RTS）游戏中，玩家可以生成步兵、弓箭手和骑士等多种类型的兵种。这些兵种出生时的属性需要根据玩家当前的科技等级动态赋予，为了高效初始化新生成的兵种单位，我们采用原型模式。
具体需求：在生成兵种时，避免每次都根据复杂的参数重新构造对象，而是基于已有的原型对象进行复制，以提高效率。

三、原型模式的实现方式

定义原型接口
- 所有能够实现复制功能的产品类（如各种兵种类）都应该实现这个克隆接口。该接口通常包含一个克隆方法，用于返回当前对象的一个副本。
具体产品类实现克隆方法
- 以骑士类为例，在构造函数中，对象需要传入很多参数进行构造。而在克隆方法的实现中，只是简单调用了类的拷贝构造方法。其他兵种类（如步兵、弓箭手）的代码实现结构与骑士类几乎完全相同。

四、原型模式的设计理念及优势

解耦对具体类的依赖
- 问题：如果直接使用拷贝构造函数，想要拷贝一个对象时，需要知道具体的类。例如，若要复制一个骑士对象，就必须明确调用骑士类的拷贝构造函数。
- 解决方案：原型模式通过让对象实现克隆接口，只需要对象实现了该接口，就能够任意复制，完全解除了对具体类的依赖。客户端代码在使用克隆功能时，无需关心对象的具体类型，只需要调用统一的克隆接口即可。
避免深拷贝、浅拷贝及对象状态污染问题
- 问题：拷贝构造函数往往涉及到深拷贝和浅拷贝的问题，在内存管理上较为复杂。而且如果不保留原型，直接使用场景中已有的对象进行拷贝，还容易拷贝多余的对象状态，造成对象状态的污染。
- 解决方案：原型模式通过提供语义更明确的克隆接口，将拷贝操作封装在对象内部，避免了这些潜在的问题。对象自己负责实现正确的拷贝逻辑，确保克隆得到的对象具有正确的属性和状态。
简化复杂对象的复制过程
- 问题：如果不在原型模式中提供克隆接口，而是在类外手动拷贝类内的字段来实现对象之间的赋值，这种方法在面对复杂字段的对象时非常繁琐。每次产生新的对象时都要手动进行字段拷贝，大大增加了人为失误的可能性。同时，类的私有字段不便在类外进行访问，并且这种方式同样需要知晓具体的子类，从而产生不必要的依赖。
- 解决方案：原型模式将拷贝逻辑封装在对象内部的克隆方法中，对象自己清楚如何正确地复制其内部的所有字段，包括私有字段。客户端只需要调用克隆方法，就可以轻松获得一个与原型对象具有相同属性的新对象，避免了手动拷贝的繁琐和错误。

五、原型模式的典型应用场景

游戏引擎中的预制体和游戏场景实例化
- 在游戏引擎中，我们创建的独立的预制体或游戏场景，在游戏运行时，通常会从文件被反序列化成原型对象。每次将这些预制体或场景实例化到游戏场景中的过程，其实都是对它的克隆，这正是原型模式的应用。
配合解释器模式实现可定制游戏角色
- 在更进阶的应用中，配合后续行为模式中讲解的解释器模式，可以实现仅通过简单的配置文件生成功能完备的可定制游戏角色。游戏开发者设计包含大部分功能的游戏角色原型，模组开发者只需要指定继承的原型，添加简单的自定义数据，在实例化时自动完成拷贝生成，便拥有了功能完备的新角色。这种应用在模组开发中非常有用，可以大大提高游戏的可扩展性和定制性。