CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章关于为何说JAVA中要慎重使用继承详解由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

前言 。

这篇文章的主题并非鼓励不使用继承，而是仅从使用继承带来的问题出发，讨论继承机制不太好的地方，从而在使用时慎重选择，避开可能遇到的坑.

java中使用到继承就会有两个无法回避的缺点:

• 打破了封装性，子类依赖于超类的实现细节，和超类耦合。
• 超类更新后可能会导致错误。

继承打破了封装性 。

关于这一点，下面是一个详细的例子（来源于effective java第16条） 。

这里自定义了一个hashset，重写了两个方法，它和超类唯一的区别是加入了一个计数器，用来统计添加过多少个元素.

写一个测试来测试这个新增的功能是否工作:

运行后会发现，加入了3个元素之后，计数器输出的值是6.

进入到超类中的addall()方法就会发现出错的原因：它内部调用的是add()方法。所以在这个测试里，进入子类的addall()方法时，数器加3，然后调用超类的addall()，超类的addall()又会调用子类的add()三次，这时计数器又会再加三.

问题的根源 。

将这种情况抽象一下，可以发现出错是因为超类的可覆盖的方法存在自用性(即超类里可覆盖的方法调用了别的可覆盖的方法)，这时候如果子类覆盖了其中的一些方法，就可能导致错误.

比如上图这种情况，father类里有可覆盖的方法a和方法b，并且a调用了b。子类son重写了方法b，这时候如果子类调用继承来的方法a，那么方法a调用的就不再是father.b()，而是子类中的方法son.b()。如果程序的正确性依赖于father.b()中的一些操作，而son.b()重写了这些操作，那么就很可能导致错误产生.

关键在于，子类的写法很可能从表面上看来没有问题，但是却会出错，这就迫使开发者去了解超类的实现细节，从而打破了面向对象的封装性，因为封装性是要求隐藏实现细节的。更危险的是，错误不一定能轻易地被测出来，如果开发者不了解超类的实现细节就进行重写，那么可能就埋下了隐患.

超类更新时可能产生错误 。

这一点比较好理解，主要有以下几种可能:

1、超类更改了已有方法的签名。会导致编译错误.

2、超类新增了方法:

• 和子类已有方法的签名相同但返回类型不同，会导致编译错误。
• 和子类的已有方法签名相同，会导致子类无意中复写，回到了第一种情况。
• 和子类无冲突，但可能会影响程序的正确性。比如子类中元素加入集合必须要满足特定条件，这时候如果超类加入了一个无需检测就可以直接将元素插入的方法，程序的正确性就受到了威胁。

设计可继承的类 。

设计可以用来继承的类时，应该注意:

• 对于存在自用性的可覆盖方法，应该用文档精确描述调用细节。
• 尽可能少的暴露受保护成员，否则会暴露太多实现细节。
• 构造器不应该调用任何可覆盖的方法。

详细解释下第三点。它实际上和 继承打破了封装性 里讨论的问题很相似，假设有以下代码:

上述代码在运行测试时就会抛出nullpointerexception :

因为超类的构造函数会在子类的构造函数之前先运行，这里超类的构造函数对somemethod()有依赖，同时somemethod()被重写，所以超类的构造函数里调用到的将是son.somemethod()，而这时候子类还没被初始化，于是在运行到date.gettime()时便抛出了空指针异常.

因此，如果在超类的构造函数里对可覆盖的方法有依赖，那么在继承时就可能会出错.

结论 。

继承有很多优点，但使用继承时应该慎重并多加考虑。同样用来实现代码复用的还有复合，如果使用继承和复合皆可(这是前提)，那么应该优先使用复合，因为复合可以保持超类对实现细节的屏蔽，上述关于继承的缺点都可以用复合来避免。这也是所谓的复合优先于继承.

如果使用继承，那么应该留意重写超类中存在自用性的可覆盖方法可能会出错，即使不进行重写，超类更新时也可能会引入错误。同时也应该精心设计超类，对任何相互调用的可覆盖方法提供详细文档.

总结 。

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我的支持.

原文链接：https://www.cnblogs.com/xz816111/p/9080173.html 。

最后此篇关于关于为何说JAVA中要慎重使用继承详解的文章就讲到这里了,如果你想了解更多关于关于为何说JAVA中要慎重使用继承详解的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。