關(guān)于為何說JAVA中要慎重使用繼承詳解
前言
這篇文章的主題并非鼓勵不使用繼承,而是僅從使用繼承帶來的問題出發(fā),討論繼承機制不太好的地方,從而在使用時慎重選擇,避開可能遇到的坑。
JAVA中使用到繼承就會有兩個無法回避的缺點:
- 打破了封裝性,子類依賴于超類的實現(xiàn)細節(jié),和超類耦合。
- 超類更新后可能會導致錯誤。
繼承打破了封裝性
關(guān)于這一點,下面是一個詳細的例子(來源于Effective Java第16條)
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,重寫了兩個方法,它和超類唯一的區(qū)別是加入了一個計數(shù)器,用來統(tǒng)計添加過多少個元素。
寫一個測試來測試這個新增的功能是否工作:
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());
}
}
運行后會發(fā)現(xiàn),加入了3個元素之后,計數(shù)器輸出的值是6。
進入到超類中的addAll()方法就會發(fā)現(xiàn)出錯的原因:它內(nèi)部調(diào)用的是add()方法。所以在這個測試里,進入子類的addAll()方法時,數(shù)器加3,然后調(diào)用超類的addAll(),超類的addAll()又會調(diào)用子類的add()三次,這時計數(shù)器又會再加三。
問題的根源
將這種情況抽象一下,可以發(fā)現(xiàn)出錯是因為超類的可覆蓋的方法存在自用性(即超類里可覆蓋的方法調(diào)用了別的可覆蓋的方法),這時候如果子類覆蓋了其中的一些方法,就可能導致錯誤。
比如上圖這種情況,F(xiàn)ather類里有可覆蓋的方法A和方法B,并且A調(diào)用了B。子類Son重寫了方法B,這時候如果子類調(diào)用繼承來的方法A,那么方法A調(diào)用的就不再是Father.B(),而是子類中的方法Son.B()。如果程序的正確性依賴于Father.B()中的一些操作,而Son.B()重寫了這些操作,那么就很可能導致錯誤產(chǎn)生。
關(guān)鍵在于,子類的寫法很可能從表面上看來沒有問題,但是卻會出錯,這就迫使開發(fā)者去了解超類的實現(xiàn)細節(jié),從而打破了面向?qū)ο蟮姆庋b性,因為封裝性是要求隱藏實現(xiàn)細節(jié)的。更危險的是,錯誤不一定能輕易地被測出來,如果開發(fā)者不了解超類的實現(xiàn)細節(jié)就進行重寫,那么可能就埋下了隱患。
超類更新時可能產(chǎn)生錯誤
這一點比較好理解,主要有以下幾種可能:
1、超類更改了已有方法的簽名。會導致編譯錯誤。
2、超類新增了方法:
- 和子類已有方法的簽名相同但返回類型不同,會導致編譯錯誤。
- 和子類的已有方法簽名相同,會導致子類無意中復寫,回到了第一種情況。
- 和子類無沖突,但可能會影響程序的正確性。比如子類中元素加入集合必須要滿足特定條件,這時候如果超類加入了一個無需檢測就可以直接將元素插入的方法,程序的正確性就受到了威脅。
設計可繼承的類
設計可以用來繼承的類時,應該注意:
- 對于存在自用性的可覆蓋方法,應該用文檔精確描述調(diào)用細節(jié)。
- 盡可能少的暴露受保護成員,否則會暴露太多實現(xiàn)細節(jié)。
- 構(gòu)造器不應該調(diào)用任何可覆蓋的方法。
詳細解釋下第三點。它實際上和 繼承打破了封裝性 里討論的問題很相似,假設有以下代碼:
public class Father {
public Father() {
someMethod();
}
public void someMethod() {
}
}
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 :
public class SonTest {
private Son son = new Son();
@Test
public void test() {
son.someMethod();
}
}
因為超類的構(gòu)造函數(shù)會在子類的構(gòu)造函數(shù)之前先運行,這里超類的構(gòu)造函數(shù)對someMethod()有依賴,同時someMethod()被重寫,所以超類的構(gòu)造函數(shù)里調(diào)用到的將是Son.someMethod(),而這時候子類還沒被初始化,于是在運行到date.getTime()時便拋出了空指針異常。
因此,如果在超類的構(gòu)造函數(shù)里對可覆蓋的方法有依賴,那么在繼承時就可能會出錯。
結(jié)論
繼承有很多優(yōu)點,但使用繼承時應該慎重并多加考慮。同樣用來實現(xiàn)代碼復用的還有復合,如果使用繼承和復合皆可(這是前提),那么應該優(yōu)先使用復合,因為復合可以保持超類對實現(xiàn)細節(jié)的屏蔽,上述關(guān)于繼承的缺點都可以用復合來避免。這也是所謂的復合優(yōu)先于繼承。
如果使用繼承,那么應該留意重寫超類中存在自用性的可覆蓋方法可能會出錯,即使不進行重寫,超類更新時也可能會引入錯誤。同時也應該精心設計超類,對任何相互調(diào)用的可覆蓋方法提供詳細文檔。
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
相關(guān)文章
詳解Spring Data操作Redis數(shù)據(jù)庫
Redis是一種NOSQL數(shù)據(jù)庫,Key-Value形式對數(shù)據(jù)進行存儲,其中數(shù)據(jù)可以以內(nèi)存形式存在,也可以持久化到文件系統(tǒng)。Spring data對Redis進行了很好的封裝,用起來也是十分的得心應手,接下來通過本文給大家分享Spring Data操作Redis數(shù)據(jù)庫,需要的朋友參考下2017-03-03
詳解Spring中@Component和@Configuration的區(qū)別
一直有同學搞不清Spring中@Component和@Configuration這兩個注解有什么區(qū)別,所以這篇文章小編就給大家簡單介紹一下@Component和@Configuration的區(qū)別,需要的朋友可以參考下2023-07-07

