我读了设计模式这本书（由四人组撰写），现在我正在重述原型设计模式。在原型设计模式的后果部分，（在第 119 页和 120 页解释）列出了以下后果：
第一个结果，通过不同的值指定新对象，在我看来并不是真正的原型设计模式的结果。结果详述，我引用：
高度动态的系统让你通过对象定义新的行为 组合——通过为一个对象的变量指定值，对于 示例 - 而不是通过定义新类。这种设计让 用户无需编程即可定义新的“类”。事实上，克隆一个 原型类似于实例化一个类。原型模式 可以大大减少系统需要的类数。
这意味着我们可以应用原型设计模式通过“克隆”和“塑造”现有类/对象来减少类。然而，这似乎并不是原型设计模式的真正“独特”结果。原型模式没有说明克隆对象的“塑造”。最重要的是，我们可以通过“新建”和“整形”来减少类而无需克隆。
第二个结果，减少子类化，似乎也不是原型设计模式的真正结果。结果详述，我引用：
Factory Method 通常会产生一个 Creator 类的层次结构， 平行于产品类别层次结构。原型模式让你 克隆一个原型而不是要求一个工厂方法来制作一个新的 目的。因此，您根本不需要 Creator 类层次结构。
当应用原型模式而不是工厂方法模式时，原型模式确实可以减少子类化。然而，这似乎又不是原型设计模式的真正“独特”结果。在产品中，Clone 函数的替代方法可以是 Create 函数。这也会使 Creator 层次结构变得多余并提供相同的结果。
我的问题：为什么类和子类减少是原型设计模式的特定结果？
我们可以在不克隆的情况下减少类，只需“新建”和“整形”即可。
newnew在产品中，Clone 功能的替代方法可以是 Create 功能。
对设计模式来说，你给函数起什么名字并不重要。这一点很重要，因为 很多 对 SO 的混淆来自于人们相信一种模式或另一种模式的本质在于其功能的名称。事实并非如此。您选择的名称当然有助于传达您的意图；但是模式的实现不是由函数名称决定的。
如果您熟悉 Java 流行的 Lombok 插件，它包含一个很好的原型变体，称为 @With，它比克隆更进一步......没有“克隆”方法。
为什么类和子类缩减是原型设计模式的特定结果？
这种减少与其他创建模式（例如工厂和建造者）形成鲜明对比，除了产品类之外，它们总是需要类和/或子类。