服务器之家:专注于VPS、云服务器配置技术及软件下载分享
分类导航

PHP教程|ASP.NET教程|Java教程|ASP教程|编程技术|正则表达式|C/C++|IOS|C#|Swift|Android|VB|R语言|JavaScript|易语言|vb.net|

服务器之家 - 编程语言 - Java教程 - 关于为何说JAVA中要慎重使用继承详解

关于为何说JAVA中要慎重使用继承详解

2021-05-25 13:14Decouple Java教程

Java继承是面向对象的最显著的一个特征,然而下面这篇文章主要给大家介绍了关于为何说JAVA中要慎重使用继承的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考借鉴,下面随着小编来一起学习学习吧

前言

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

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

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

继承打破了封装性

关于这一点,下面是一个详细的例子(来源于effective java第16条)

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class myhashset<e> extends hashset<e> {
 private int addcount = 0;
 
 public int getaddcount() {
  return addcount;
 }
 
 @override
 public boolean add(e e) {
  addcount++;
  return super.add(e);
 }
 
 @override
 public boolean addall(collection<? extends e> c) {
  addcount += c.size();
  return super.addall(c);
 }
}

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

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

?
1
2
3
4
5
6
7
8
9
10
public class myhashsettest {
 private myhashset<integer> myhashset = new myhashset<integer>();
 
 @test
 public void test() {
  myhashset.addall(arrays.aslist(1,2,3));
  
  system.out.println(myhashset.getaddcount());
 }
}

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

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

问题的根源

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

关于为何说JAVA中要慎重使用继承详解

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

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

超类更新时可能产生错误

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

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

2、超类新增了方法:

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

设计可继承的类

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

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

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

?
1
2
3
4
5
6
7
8
public class father {
 public father() {
  somemethod();
 }
 
 public void somemethod() {
 }
}
?
1
2
3
4
5
6
7
8
9
10
11
12
public class son extends father {
 private date date;
 
 public son() {
  this.date = new date();
 }
 
 @override
 public void somemethod() {
  system.out.println("time = " + date.gettime());
 }
}

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

?
1
2
3
4
5
6
7
8
public class sontest {
 private son  son = new son();
 
 @test
 public void test() {
  son.somemethod();
 }
}

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

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

结论

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

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

总结

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

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

延伸 · 阅读

精彩推荐