原型模式（Prototype Pattern）是面向对象设计中一个典型的创建型设计模式。在 GoF 的《设计模式：可复用面向对象软件的基础》中，原型模式被赋予了一个精炼的标准定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。这句话蕴含着原型模式区别于其他创建型模式的全部精髓——创建对象不一定非要依赖 new 关键字调用构造函数，还可以通过复制一个已存在的对象来完成。
理解这个概念，首先要厘清三个核心术语。原型对象是被复制的源对象，通常处于初始化完毕、状态稳定的阶段；克隆指以原型对象为模板，生成一个与其状态相同的新对象的过程；拷贝描述的则是克隆发生时，对象内部各字段值从原型对象向新对象传递的方式。这三个术语构成了原型模式的语义基石，后续考点都围绕它们展开。
从类结构上看，原型模式涉及三个角色。抽象原型类是基类，它声明一个克隆自身的接口，通常命名为 clone 方法，返回类型为抽象原型类自身；具体原型类实现该接口，完成实际的自我复制；客户端则通过调用具体原型对象的 clone 方法，获得一个与原型状态一致的新实例。在 Java 语言中，这个克隆接口通常由 Cloneable 标记接口以及 Object 类中的 clone 方法共同承担。
需要特别强调的是，原型模式属于创建型设计模式的范畴。创建型模式关注对象创建机制，它与结构型模式关注类与对象的组合、行为型模式关注对象之间的职责分配与交互，有着本质区别。在软考中，把原型模式正确归类到创建型，是最基础也最容易拿分的判断点。命题人常把单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式这五种创建型模式混在一起，让考生辨析各自的使用场景，其中原型模式最鲜明的识别标志，就是题目描述中出现了复制、克隆、拷贝、快速生成相似对象这类关键词。
原型模式存在的根本理由，在于某些场景下直接调用构造函数创建对象的成本过高，甚至不可行。设想一个对象在创建时需要执行大量复杂初始化逻辑，例如从数据库加载海量数据、建立网络连接、加载配置文件，那么每次从零创建都会重复付出高昂代价；而如果已存在一个初始化完毕的实例，只要复制它，就能在极短时间内获得一个状态等价的新对象，绕开那些昂贵的初始化过程。
更深一层的原因在于，某些对象的具体类型在编译期无法确定。当程序需要根据运行时加载的类来创建对象时，new 关键字要求明确写出具体类名，这会让代码与具体类强耦合。原型模式允许把一个对象注册为原型，运行时动态地复制它，而无需知道其具体类型，这为程序带来了更大的灵活性和可扩展性，也为框架和插件机制提供了基础。
克隆机制的实现，本质上是内存层面的复制。当调用一个对象的 clone 方法时，虚拟机会在堆内存中为新对象分配一块新空间，然后把原型对象的字段值复制到新对象对应的字段中。这个复制过程的细节，决定了克隆是浅拷贝还是深拷贝，而这也是整个原型模式中最核心、最易被命题人挖坑的地方。
以 Java 语言为例，Object 类中提供了一个受保护的本地方法 clone，它的默认行为就是浅拷贝。所谓浅拷贝，指的是只复制对象本身，对于对象内部包含的引用类型字段，仅仅复制引用本身，而不复制引用所指向的被引用对象。换句话说，浅拷贝得到的新对象，其引用类型字段与原对象指向的是同一块堆内存中的同一个对象，这意味着通过新对象修改被引用对象的内容，原对象也会随之改变。
浅拷贝与深拷贝的区别，是原型模式考点的重中之重。浅拷贝只复制对象的一层结构，对于引用类型字段，新旧对象共享同一个被引用对象；深拷贝则要求把引用类型字段所指向的对象也一并递归地复制出来，使新旧对象在对象图上完全独立、互不干扰。
用一个具体例子来说明。假设存在一个简历对象，它内部包含一个工作经历对象。若对简历做浅拷贝，得到的新简历与原简历拥有各自独立的外壳，但内部的工作经历字段指向同一对象，此时修改新简历的工作经历，原简历也会改变。若做深拷贝，工作经历对象也会被复制一份，新旧简历各自拥有独立的工作经历对象，互不影响。
深拷贝的实现方式主要有三种。第一种是手动递归复制，即在 clone 方法中，除了复制基本类型字段外，还要对每一个引用类型字段分别调用其 clone 方法，进行逐层递归的复制。这种方式最为直观，但当对象的引用结构复杂、嵌套层次深、字段众多时，代码会变得冗长且难以维护。
第二种是借助序列化机制实现深拷贝。把原对象序列化成字节流，再从字节流反序列化出一个新对象，这个新对象与原对象在内存中是完全独立的，因为序列化和反序列化过程会重建整个对象图。这种方式的优点是实现简单、通用性强，只要对象及其引用链上的所有对象都实现了序列化接口即可；缺点是性能开销较大，且对无法序列化的字段无能为力。
第三种是利用对象映射工具或第三方库完成深拷贝，其本质也是通过反射或序列化等机制递归地复制对象图。在软考的考查范围内，考生只需掌握前两种方式的原理与适用条件即可。
在实际工程中，原型模式常常会引入一个原型管理器，也就是原型注册表。原型管理器维护一个映射，把原型对象的名称或标识与具体的原型对象关联起来。客户端需要创建对象时，先从原型管理器按名称查找对应的原型对象，再调用其 clone 方法获得副本。原型管理器让原型模式具备了按需创建、集中管理的能力，当系统中有多个可克隆的原型时，这种集中管理的方式尤为有效。在软考真题中，如果题目描述出现了对象缓存、按名称获取克隆源、集中存放可复制模板等特征，往往就指向了带原型管理器的原型模式。
从形态上划分，原型模式可以粗略地分为两种变体。第一种是简单原型模式，即系统中只存在一个或少数几个原型对象，客户端直接持有原型对象的引用，需要时直接调用其 clone 方法即可，结构最为简洁。第二种是带原型管理器的原型模式，它在简单原型模式的基础上增加了一个原型管理器，负责统一登记和分发各个原型对象，适用于原型种类较多、需要动态增删原型的系统。
这两种变体在类图上的差别，就在于是否存在一个原型管理器角色。软考题目中，凡是出现了类似对象池、原型库、模板库、复制工厂这类集中存放和分发可复制对象的概念，考生都应当联想到带原型管理器的原型模式这一变体。
按照克隆的深度，原型模式又可以分为浅拷贝原型和深拷贝原型。浅拷贝原型实现简单、速度快，但要求被克隆对象的引用类型字段要么是不可变对象，要么共享引用是可以接受的。深拷贝原型实现复杂、速度慢，但能保证新旧对象完全独立。在实际设计中，究竟采用浅拷贝还是深拷贝，取决于业务语义：如果被引用对象需要被多个克隆体共享，且共享不会引发问题，浅拷贝即可；如果每个克隆体都必须拥有独立的内部状态，则必须使用深拷贝。
这里有一个易被忽视的细节：字符串这类不可变对象无法被修改，浅拷贝虽未复制其内容，共享引用却不会引发数据不一致，因此字符串字段通常无需深度复制。命题人有时会利用这一点设陷阱，让考生误以为字符串字段也必须深拷贝。
原型模式的适用场景可以归纳为四类。第一类，对象创建成本高昂，而初始化一个与已有对象状态相近的新对象，通过复制比通过新建更加经济，例如从数据库中加载大量数据构建出的复杂对象。第二类，系统需要保存对象在某一时刻的快照，以便后续恢复到该状态，原型模式天然适合作为快照机制的基础。第三类，对象的类型需要在运行时动态确定，程序无法在编译期硬编码具体的类名，此时原型模式提供了一种解耦的创建方式。第四类，系统需要大量创建结构相同但状态略有差异的对象，例如一份简历模板可以克隆出多份，再对每份进行局部修改。
简历自动生成、报表模板复制、配置对象快照、缓存对象复用等场景，都是原型模式的典型出题素材，考生看到这些描述时应能迅速锁定答案。
原型模式与工厂方法模式、抽象工厂模式、单例模式、建造者模式同属创建型模式，但它们解决问题的角度各不相同。工厂方法模式把对象的创建延迟到子类，通过继承来扩展；抽象工厂模式强调创建一族相关对象；建造者模式关注把一个复杂对象的构建过程与它的表示分离；单例模式保证一个类只有一个实例。原型模式则独树一帜，它不关心如何从零构造对象，而是以已有对象为模板进行复制。
在真题中，这五种创建型模式的辨析是高频考点。原型模式与其他四种模式最本质的区别，就在于它创建对象的方式是复制而非新建。命题人往往会在题目中埋入复制、克隆等关键词，作为识别原型模式的线索，考生只要抓住了复制这个核心动作，就能
本篇完！