您似乎认为这两点是相互排斥的。他们不是。继承是面向对象编程的基本和强大的原则，它被过度使用。
它通常被缺乏经验的开发人员过度使用，他们对继承的想法如此着迷，以至于他们更关注继承树而不是解决问题。他们试图将尽可能多的代码分解到某些父基类中，以便他们可以在整个树中重用它，结果他们的设计很脆弱。
软件工程的最大弊端之一是类之间的紧密耦合。在客户要求进行简单更改后，这种情况会导致您不得不在周末工作。为什么？因为在一个类中进行更改会影响另一个类，而修复该类会影响另一个类，依此类推。
好吧，没有比继承更紧密的耦合了。
当您将太多因素考虑到“顶层”时，每个派生类都会与之耦合。随着您发现越来越多的代码需要分解到各个级别，您最终会拥有这些深层树，并且在顶部进行的每项更改都会在整个树中级联。结果，您开始拥有返回null或为空的方法。它们对于类来说是不必要的，但继承契约要求它们存在。这违反了里氏替换原则。
所以当然要使用继承。但要聪明地做。如果您有任何疑问，请支持委托继承。并且当您使用继承时，请确保您不是为了重用通用代码而将通用性分解到（整个树或子树的）顶层，而是因为从上到下存在共同的行为。
如果你的树的深度超过两到三层（我认为三层真的在推动它），那么你几乎肯定会给自己带来麻烦。
适度的一切都很好。请记住，这句话并不是说不要使用它，或者避免使用它等等。而是说它是一个过度使用的主体，而其他 OO 抽象或主体工作得更好。继承很强大，但它的耦合很紧密。
UML 书的作者明智地或相当随机地指出，继承经常被过度使用和过度引用这一当前不言而喻的说法。那么所有其他的原则和抽象呢？我发现开发人员通常只点击 OO 亮点（继承是一个）并过度使用该抽象。
在 UML 中对我来说，UML 通常是 OO 是一个很好的提醒，但它不限于 Java 或 .Net OO 特性。许多语言只提供所有语言可用的抽象。UML 试图帮助您建模和表达其中的许多。
请记住作者只说“用得太多”，没有不好或不正确。还要记住，也许您是一位不会错误地应用继承的专家开发人员。