为什么子类太糟糕了(因此我们为什么要使用原型来废除它)？

Question

我在阅读设计模式，我读到原型设计模式消除了过多的子类。

为什么子类是坏的？与子类相比，使用原型会带来什么优势？

Answer 1

为什么子类太多坏

“太多”是判断力的判断，但从我这里夺走它是不好的。我所使用的代码具有很深的继承性，代码很难阅读、理解、跟踪、跟踪、调试等等。实际上，编写测试代码是不可能的。

原型模式消除了子类

或者这个问题的意思是“消除太多的子类？”这种模式要求克隆一个“模板”对象以避免子类化，至少在这一点上是这样的。没有规则说“模板”不能是子类。

偏好组合而不是继承

这里的想法还包括委托和聚合。遵循这种启发意味着您的软件更灵活、更易于维护、扩展和重用。

当类由部分组成时，可以在运行时替换这些部件。这对可测试性有着深远的影响。

测试更容易。您可以使用假部件(即“模拟”，“双”和其他测试-交谈)。我们的代码的深度继承意味着我们必须实例化整个层次结构来测试其中的任何一点。在我们的例子中，如果不在实际环境中运行代码，这是不可能的。例如，我们需要一个数据库来实例化业务对象。

变化伴随着副作用和不确定性--阶级的“基础”越多，影响就越广泛，无论好坏。由于副作用的不确定性，可能会有你不敢做的改变。或者，对我们的继承链中的某个地方有利的改变对另一个地方是不利的。这当然是我的经验。

Answer 2

我认为，这被认为是一种糟糕的做法的原因之一是，随着时间的推移，每个子类都可以包含对该对象毫无意义的属性和方法，这样您就越往下走(在一个开发很差的层次结构中)。您可能最终得到一个臃肿的类，其中包含对该类没有意义的项。

我自己也不知道这事。只说不好就显得教条了。误用任何东西都是坏事。

Answer 3

在某些情况下，继承会破坏封装，如果确实发生这种情况，则是不好的。再读一遍。

在过去没有继承的情况下，库会发布一个API和使用它的应用程序，使用它可以使用公开可见的内容，而库现在有了自己的方法来处理不断变化的内部齿轮，而不破坏应用程序。

随着需求的发展，库可以进化，可以拥有更多的客户；或者，它可以通过从自己的类继承其他样式来提供扩展功能。到目前一切尚好。

但是，最基本的是，如果应用程序获取类并开始子类，那么现在子类实际上是客户端而不是内部合作伙伴。但是，与定义公共API的明确方式不同，子类现在在库中更深入(访问所有私有变量等等)。还不算坏，但是一个讨厌的角色可以架起API的桥梁，这个API在应用程序中和库中都太多了-

从本质上讲，虽然情况并不总是如此，但是，

很容易滥用继承来破坏封装。

允许子类化可能是错误的，如果这一点。