面向对象中的继承真的几乎“一无是处”吗？
题目表述得或许有些极端了。问题的具体描述是这样的，一直以来都有许多人指出面向对象中的“继承”在绝大多数情况下可以被其他更好的解决方案，如接口（或者叫做协议、特性）、委托、混入等方式实现。而通过继承共享代码则会带来“继承税”，并逐渐使代码难以维护。

然而继承在我个人看来似乎是一种非常自然的思维方式，即使是容易产生菱形继承问题的多继承本身在自然界中也是普遍存在的，而且在实现中也是可以利用线性化解决的。而继承带来的耦合性，例如更换父类方法实现产生的额外成本，本身也是在一定程度上能够通过IDE的安全重构缓解的。继承是否真的有许多人讨论得那样不堪，问题是在于继承本身还是在于其滥用？

而根据我的个人经历（作为一个软件工程专业的本科生），学校中也开了相当多课程是有关面向对象分析的，而这其中大量涉及了UML图中类图的设计，常常能见到多层次继承树的出现。如果选择完全摒弃继承，使用类图来描述代码组织似乎也变得没太大意义了。这意味着这类传统的面向对象分析模式已经不适应新的开发理念了吗？

但是，我又看到有一些新诞生的编程语言，如Rust和Go，直接抛弃了继承，而使用组合或trait等方式来实现多态与代码复用。使用这些语言也开发出了许多成功的项目，这意味着“继承”将在新兴编程语言中慢慢消失吗？

思绪有些混乱，因此描述得不是很清楚，请见谅。
继承并不是一无是处，也并非是面向对象的专利，除了`public`继承可以表达运行时多态语义（is-a）之外，它还可以表达 **组合语义**，尤其是private/protected继承，这对于缺少继承特性的语言来说是比较遗憾的，这里分两个方面阐述。

首先是面向对象的多态，C++中的经典做法是通过`public`继承接口类实现，C是手工构造虚函数表，在某些语言中不使用继承表达运行时多态，由此可知未必需要继承特性表达面向对象的多态。但继承的好处是对于一个对象实现了哪些接口可以一目了然，而不需要依赖其他工具生成相关文档说明。

另一点是组合语义（分离关注点），这有点类似于其他语言提供的Mixin特性。传统的通过成员变量的方式表达组合，往往意味着大量无聊的转调（委托）代码，阅读某些缺少继承的语言标准库代码便能体会到。

综上，你可以不用，但不能没有。