最近，我回过头来阅读“UML参考手册”第二版的一些部分（显然是：Booch，Rumbaugh，Jacobson）。
（见：http://www.amazon.com/Unified-Modeling-Language-Reference-Manual/dp/020130998X）
与此同时，我在“UML的复杂性”部分的第一章“UML概述”中找到了这些“奇怪的”字样：
过分使用泛化是以牺牲本质区别为代价的。继承总是好的神话一直是从最初几天起就是对象的诅咒。
我无法看到这句话如何完全符合面向对象的范式，该范式指出继承是一个基本原则。
有任何想法/帮助吗？
答案 0 :(得分：1)
你似乎相信这两点是相互排斥的。他们不是。继承是面向对象编程的一个基本而强大的原则，和它被过度使用。
通常由缺乏经验的开发人员过度使用，他们如此着迷于继承的想法，他们更关注继承树而不是解决问题。他们试图将尽可能多的代码分解为某些父类，这样他们就可以在整个树中重复使用它，结果它们的设计很脆弱。
软件工程最大的弊端之一是类之间的紧密耦合。在客户要求进行简单更改之后，这就是导致您必须在周末工作的事情。为什么？因为在一个类中进行更改会对另一个类产生影响，并且修复该类会对另一个类产生影响，等等。
嗯，没有比继承更紧密的耦合。
当你对“顶级”的影响太大时，每个派生类都与它相关联。当您发现越来越多的代码要分解到各个级别时，您最终会拥有这些深层树，并且在整个树中的顶级层级中进行的每个更改。因此，您开始拥有返回null或为空的方法。它们对于课堂来说是不必要的，但继承合同要求它们在那里。这违反了Liskov Substitution Principle。
所以当然要使用继承。但要巧妙地做到这一点。如果您有任何疑问，请将委托转移到继承。当你使用继承时，确保你没有将共同点（整个树或子树的顶层）分解为重用公共代码，而是这样做，因为存在行为的共性从上到下。
如果你的树深度超过两层或三层（我认为其中有三层真正推动它），你几乎肯定会让自己陷入困境。
答案 1 :(得分：0)
适度的一切都很好。请记住，引用并不是说不使用它，或者避免使用等等。相反，当其他OO抽象或委托人工作得更好时，它就是说它是一个过度使用的主体。继承是强大的，但它的耦合很紧张。
UML书籍的作者明确地或者说是随意地指出这一当前的说法，即继承经常被过度使用和过度引用。所有其他原理和抽象怎么样？我发现开发人员通常只会点击OO亮点（继承是一个）并使用该抽象过多。
对于我来说，在UML中，一个很好的提醒是UML通常是OO，但它不仅限于Java或.Net OO功能。许多语言仅提供所有语言的抽象。 UML试图帮助您建模和表达其中的许多内容。
请记住，作者只说“使用太多”，不是坏或不正确。还要记住，也许你是一个专家开发人员，他没有错误地应用继承。