Oop 对“中”一句话的误解；UML参考手册；书（布希、伦堡、雅各布森）

最近，我回头阅读了《UML参考手册》第二版的一些部分（显然作者：Booch、Rumbaugh、Jacobson）

（见：）

同时，我在“UML的复杂性”一节的第一章“UML概述”中发现了这些“奇怪”的词：

以牺牲本质区别为代价的泛化太多了。从最早的时候起，继承总是好的神话就是面向对象的诅咒

我看不出这句话怎么能完全符合面向对象范式，即继承是一个基本原则

---

有什么想法/帮助吗？

你似乎认为这两点是相互排斥的。事实并非如此。继承是面向对象编程的一个基本而强大的原则，它被过度使用

它通常被缺乏经验的开发人员过度使用，他们对继承的概念如此着迷，以至于他们更关注继承树而不是解决问题。他们试图将尽可能多的代码分配给某个父基类，这样他们就可以在整个树中重用它，因此他们的设计很脆弱

软件工程最大的弊病之一是类之间的紧密耦合。这类事情会让你在客户要求一个简单的改变后不得不工作到整个周末。为什么？因为在一个类中进行更改会对另一个类产生影响，而修复该类会对另一个类产生影响，依此类推

嗯，没有比继承更紧密的耦合了

当您将太多的因素考虑到“顶层”时，每个派生类都与之耦合。当你发现越来越多的代码需要分解到不同的层次时，你最终会得到这些深层的树，在树的顶部所做的每一个改变都会在整个树中级联。因此，您开始有返回

null

或为空的方法。它们对于类来说是不必要的，但是继承契约要求它们在那里。这违反了法律

所以当然要使用继承。但要做得巧妙。如果您有任何疑问，请支持授权继承。当您确实使用继承时，请确保您不是为了重用公共代码而将公共性分解到顶层（整个树或子树），而是因为从上到下都有行为的公共性

---

如果你的树有两三层深（我认为三层真的在推它），你几乎肯定是在给自己制造麻烦。

适度的一切都是好的。记住，这句话并不是说不要使用它，或者避免，等等，而是说当其他OO抽象或主体工作得更好时，它是一个被过度使用的主体。继承是强大的，但它的耦合是紧密的

这本UML书的作者明智地或随意地指出了当前的真理，即继承经常被过度使用和引用。那么所有其他的原则和抽象呢。我发现开发人员通常只关注OO重点（继承就是其中之一），过度使用抽象

对我来说，在UML中这是一个很好的提醒，UML通常是面向对象的，但它并不局限于Java或.NETOO特性。许多语言只提供跨所有语言的抽象。UML试图帮助您建模和表达其中的许多内容

---

记住作者只说了“太多使用”，不是坏的或不正确的。还请记住，您可能是一位不会错误应用继承的专家开发人员。

我没有这本书，因此没有上下文，但我想他们强调了一种趋势，即继承只用于获得重用，而类之间没有“IsA”的概念，然而，或组合等将是更合适的重用机制。例如，90版中的许多C++框架有一个无处不在的“CopEdpe”或“ToTobe”基础。希望它能帮助您。如果是这样的话，一个兄弟能得到一张赞成票或一张接受票吗？哈哈。谢谢你的反馈，是的，我同意滥用deep tree会导致耦合问题的事实，在某些情况下建议委派/组合。。。但对我来说仍然有一件事是不可理解的：正如上面引用的，似乎[Booch、Rumbaugh和Jacobson]会说UML复杂性，特别是与继承有关！！！怎么可能呢？