没有继承的 OOP 重用：“现实世界”如何实现这个实用吗？

Question

本文描述了一种我觉得很有趣的 OOP 方法：

如果对象存在为 封装和通信 通过消息？如果代码重用了怎么办 与继承无关，但是 使用组合、委托，甚至 老式的辅助对象或任何 程序员认为合适的技术？ 本体并没有消失，但它 与实现分离。

我发现最令人震惊的是，无需继承或依赖于类层次结构即可重用的想法，但这有多可行呢？

给出了示例，但我不太明白如何更改当前的代码以适应这种方法。

那么这种方法的可行性如何呢？或者真的不需要更改代码，而是需要“仅在需要或最佳时使用”的基于场景的方法？

编辑：哎呀，我忘记了链接：这里是 链接

Answer 1

我相信您听说过“总是更喜欢组合而不是继承”。

这一前提的基本思想是将具有不同功能的多个对象组合在一起以创建一个功能齐全的对象。这应该优于从彼此无关的不同对象继承功能。

关于这一点的主要论点包含在里氏替换原理的定义中，并由这张海报有趣地说明:

如果您有一个 ToyDuck 对象，从纯粹继承的角度来看，您应该从哪个对象继承？你应该继承Duck吗？不——很可能你应该从 Toy 继承。

最重要的是，您应该为代码使用正确的抽象方法（无论是继承还是组合）。

对于您当前的对象，请考虑是否存在应该从继承树中删除并仅作为您可以调用和调用的属性包含在内的对象。

Answer 2

继承不太适合代码重用。为了代码重用而进行继承通常会导致：

1. 具有继承方法的类不得在其上调用（违反里氏替换原则），这会让程序员感到困惑并导致错误。
2. 当可以在十几个或更多类中的任何位置声明所需的方法时，层次结构很深，需要花费大量时间才能找到所需的方法。

一般来说，继承树的深度不应超过两层或三层，并且通常您应该只继承接口和抽象基类。

然而，仅仅为了重写现有代码是没有意义的。但是，当您需要修改时，请尽可能尝试切换到合成。这通常允许您以较小的部分修改代码，因为类之间的耦合会减少。

Answer 3

我只是浏览了一下文本，但它似乎说明了 OO 设计始终是关于什么的：继承并不意味着作为代码重用工具，松散耦合是好的。 这之前已经写了几十次了，请参阅文章底部的链接参考文献。这并不意味着您应该完全跳过继承，您只需有意识地使用它，并且仅在有意义时使用它。文章中也指出了这一点。

至于鸭子打字，我发现例子和想法有问题。就像这样：

function good (foo) {
  if ( !foo.baz || !foo.quux ) {
    throw new TypeError("We need foo to have baz and quux methods.");
  }
  return foo.baz(foo.quux(10));
}

添加三行新行只是为了报告运行时自动报告的错误有什么意义？

Answer 4

继承是根本

，没有继承，就没有OOP。

原型和委托可以用来实现继承（就像在 JavaScript 中一样），这很好，并且在功能上等同于继承

对象、消息和组合，但没有继承是基于对象的，而不是面向对象的。 VB5，不是Java。是的，可以做到；计划编写大量样板代码来公开接口和转发操作。

那些坚持认为继承是不必要的，或者继承是“坏”的人正在创造稻草人：很容易想象继承被滥用的场景； 这不是对工具的反映，而是对工具用户的反映。