"继承是否应该避免"的想法源自哪里？

Question

最近我们讨论了这里提到的一个缺陷,其中一方表示"是的,这就是为什么书籍说应该避免继承."

我已经使用了多年的继承,并发现它在许多设计案例中非常有用和方便.此外,我确信这个人至少会误解这些"书说"的内容.

真的有一种想法,继承有点坏,应该避免吗？它来自哪里,我在哪里可以了解更多？

Answer 1

我认为他可能意味着继承可能被过度使用,即使在组合是更好的解决方案的情况下也是如此.这在几本书中讨论,例如

• 有效的Java第2版,第16项:支持组合而不是继承

继承是实现代码重用的有效方法,但它并不总是最适合工作的工具.使用不当,会导致软件脆弱.在包中使用继承是安全的,其中子类和超类实现在同一程序员的控制之下.在扩展专门为扩展而设计和记录的类时,使用继承也是安全的(第17项).但是,跨越包边界继承普通的具体类是危险的.提醒一下,本书使用"继承"一词来表示实现继承(当一个类扩展另一个类时).此项中讨论的问题不适用于接口继承(当类实现接口或一个接口扩展另一个接口时).

与方法调用不同,继承违反了封装 [Snyder86].换句话说,子类依赖于其超类的实现细节来实现其正确的功能.超类的实现可能会在不同版本之间发生变化,如果确实如此,子类可能会中断,即使其代码未被触及.因此,子类必须与其超类一起发展,除非超类的作者为了扩展而专门设计和记录它.

• Effective C++ 3rd Edition有几个与此相关的项目:
  • 第32项:确保公共继承模型"是-a".
  • 第34项:区分接口的继承和实现的继承
  • 第38项:模型"有一个"或"通过组合实现"