很多Java程序员喜欢将“面向对象三大特性”奉为圭臬，特别是“继承”，在他们眼中，“继承”是“面向对象”最重要的特性，但事实上广义的“面向对象”并没有限定必需“继承”，甚至“面向对象”这个概念在业界上也还没达成统一，比如像Go和Rust这类不支持“继承”的编程语言，也有很多人认为它们是“面向对象”的语言。
今天我就想给很多Java程序员们泼一盘冷水：“类继承”是有害的。
为什么我明确是“类继承”呢？因为“接口继承”并不在此列，所以需要特别指出。
我的观点是：在所有的大型Java项目中，凡是最难以维护、难以修改、难以阅读、牵一发而动全身的代码，必然是那些使用了“类继承”的代码。
这是因为“类继承”违反了一个设计原则：最小职责原则。
对于父类来说，它即是实现又是抽象。实现是对于父类本身而言，它可以被实例化成对象；而抽象则是对于子类来说，它是子类的抽象。这两个特性分开来都说好特性，组合在一起就变成了难吃的五仁月饼。
对于实现而言，父类就不可能做得太小，因为它是有功能性的，即使它把单一的功能拆散成多个类再组合起来，这样对于子类来说，也是继承了父类的全部，而这恰恰造成了很大的耦合度——要是在将来重构发现子类不需要某个方法，也无法去掉，因为一旦去掉，就不满足父类了。你可能觉得可以在方法体里抛个异常即可，但是对于调用方来说，一旦不知道这一点，就会出现BUG，一旦系统中这种设计越来越多，整个系统就会混乱不堪，就像缝缝补补的破裤子一样。
而对于抽象来说，父类承担起了接口的责任，一个巨大的接口，这也是Java程序员津津乐道的“多态”。但是可怕的是，父类的多态类，有可能是它继承树下面的所有子类中的其中一个，而这个子类，又可能是其他子类的父类，你需要了解整个继承链路上的所有子类；而对于接口而言，实现类就是一张铺平的网，你要了解的这里的其中一个即可。
经验丰富的Java程序员有一种说法：“类继承不能够超过三层，否则就会造成混乱”。这是根据经验而得出的结论，而对于“接口继承”来说，却没有这种说法，一方面是接口很少情况会需要这么多层的继承，另一方面是即使超过100层的接口继承，也不会造成混乱。这是为什么？
因为“类继承”的混乱是指数级别的增长，而“接口继承”则是线性增长。对于混乱程度，物理学上把这种程度定义成熵，熵的符号是S，假设继承层数是N，那么，“类继承”的熵就是，而“接口继承”则是
。
在多层继承里，方法的覆盖会非常混乱，你不知道方法到底在哪里被覆盖了，继承链路上所有子类都有可能是罪魁祸首。而对于接口来说，即使是接口中的方法是默认方法，也没关系，因为只有实现类最终会调用到方法，更重要的是，接口不会被实例化，因此它可以包含最少的方法，就是所谓的单一职责原则，而让实现类实现多个接口。这样接口就没有必要去继承了。
随着组合由于继承的观念深入人心，很多主流的框架和组件都放弃了继承，比如Spring，你基本上不需要用到继承，除非你自作主张。
在Java8之前，“类继承”尚且有他存在的意义，那就是代码复用；而在Java8之后，由于接口有了默认方法这一特性，“类继承”就变成了彻头彻尾的垃圾——抱歉我用“垃圾”两字来形容它，因为我真的不想看到那些使用了继承还沾沾自喜的代码了。
