前言
這是Java Rules系列的第二篇, 繼續(xù)介紹一些規(guī)則和技巧。
1. 多用組合少用繼承
這個(gè)規(guī)則其實(shí)在很多書中都提到過(guò)，在《重構(gòu)》這本書中也有一個(gè)章節(jié)詳細(xì)描述了原因，總結(jié)下來(lái)主要就是因?yàn)樽宇愐蕾囉诔愔械奶囟üδ?，超類可能隨著不斷迭代，功能內(nèi)容有所修改，但是子類是繼承自超類的，如果超類的基礎(chǔ)功能發(fā)生變化，那么子類在代碼完全沒有變化的情況下，可能功能也發(fā)生了變化，產(chǎn)生了變化傳導(dǎo)效應(yīng)，對(duì)于分析問題和代碼閱讀可能都會(huì)存在不好的影響。而且寫過(guò)代碼的同學(xué)應(yīng)該都有感觸，在閱讀別人代碼的時(shí)候，如果代碼中存在太多的繼承關(guān)系，那么閱讀起來(lái)是非常累的，而且很容易漏掉一些關(guān)鍵代碼，所以總結(jié)下來(lái)就是在不是必須用繼承的時(shí)候盡量少用繼承，用組合來(lái)實(shí)現(xiàn)功能復(fù)用，這樣代碼閱讀起來(lái)會(huì)更加簡(jiǎn)單。
2. 基于接口編程
上一條說(shuō)了少用繼承，但是這里說(shuō)的繼承不是實(shí)現(xiàn)，不要理解錯(cuò)了，實(shí)現(xiàn)是一個(gè)類針對(duì)一個(gè)接口來(lái)說(shuō)的，我們是推薦基于接口編程的?；诮涌诰幊套畲蟮暮锰幘褪钦{(diào)用方調(diào)用的都是接口，它不關(guān)心接口后面的具體實(shí)現(xiàn)，這樣就做到了功能模塊之間的松耦合，并且模塊內(nèi)部的接口實(shí)現(xiàn)可以隨意方便的變化，只要新的實(shí)現(xiàn)能夠涵蓋所有的方法就可以了，這樣調(diào)用方在調(diào)用的接口的時(shí)候完全感知不到接口已經(jīng)變動(dòng)。
舉個(gè)例子：在android的UI頁(yè)面模塊需要調(diào)用網(wǎng)絡(luò)請(qǐng)求，我們可以直接在頁(yè)面中起一個(gè)子線程去調(diào)用httpclient的網(wǎng)絡(luò)請(qǐng)求，但是如果這樣實(shí)現(xiàn)的話使用起來(lái)肯定是沒問題的，但是當(dāng)我們發(fā)現(xiàn)httpclient不好用了，要換okhttp，程序員一定會(huì)大怒，okhttp的網(wǎng)絡(luò)請(qǐng)求接口和httpclient是不一樣的，如果改的話，我需要改很多地方。但是如果我們換一種方法實(shí)現(xiàn)，那么結(jié)果就會(huì)不一樣，自己創(chuàng)建一個(gè)網(wǎng)絡(luò)請(qǐng)求接口NetWorkClient，接口中定義了我們常用的get、post請(qǐng)求方法，入?yún)檎?qǐng)求參數(shù)的map或者是我們自定義的requestParam對(duì)象，我們可以封裝一個(gè)網(wǎng)絡(luò)實(shí)現(xiàn)類HttpClientImp類，這個(gè)類基于httpclient實(shí)現(xiàn)了NetWorkClient接口中的get和post方法，在調(diào)用模塊中直接調(diào)用NetWorkClient接口的get或者post方法，那么對(duì)于調(diào)用模塊來(lái)說(shuō)，它不知道后面的具體實(shí)現(xiàn)是哪個(gè)類，但是接口請(qǐng)求到了。這個(gè)時(shí)候如果要換成用okhttp網(wǎng)絡(luò)實(shí)現(xiàn)，那么直接用okhttp實(shí)現(xiàn)NetWorkClient接口的方法就可以了，調(diào)用方的NetWorkClient接口對(duì)象注入的時(shí)候，注入新的網(wǎng)絡(luò)請(qǐng)求類就可以了，調(diào)用模塊里的方法完全不用修改，可以做到完全無(wú)感知替換底層網(wǎng)絡(luò)實(shí)現(xiàn)。
3. 集合類一定不要使用原始類
我們?cè)诰幋a過(guò)程中經(jīng)常會(huì)用到集合類，例如List、HashMap、Queue等，這些集合類java是允許直接定義、直接使用的，例如List list = new ArrayList();但是對(duì)于初始化出來(lái)的list，我們可以隨便add對(duì)象進(jìn)去，因?yàn)榧项惸J(rèn)的集合item為Object，那么我們?cè)趯?duì)集合進(jìn)行增加減少，在代碼層面編譯可能不會(huì)報(bào)錯(cuò)，但是執(zhí)行的時(shí)候從list取出對(duì)象使用的時(shí)候可能報(bào)運(yùn)行時(shí)錯(cuò)誤。
這就要求我們?cè)诙x集合類對(duì)象的時(shí)候，最好指定好泛型List<String> list = new ArrayList<String>();，這樣在編譯階段誤插的對(duì)象如果類型不對(duì)，就直接報(bào)錯(cuò)了，不會(huì)等到運(yùn)行時(shí)可能發(fā)生的偶發(fā)錯(cuò)誤。還有個(gè)好處就是從集合中刪除元素時(shí)不需要再進(jìn)行手工轉(zhuǎn)換了，編譯器會(huì)自動(dòng)插入隱式的轉(zhuǎn)換，并確保不會(huì)失敗。
4. 優(yōu)先考慮泛型
我們?cè)谌粘ｉ_發(fā)過(guò)程中經(jīng)常遇到一些看起來(lái)差不多的類，處理邏輯都是一樣，只是針對(duì)的對(duì)象不同，這個(gè)時(shí)候我們就應(yīng)該要考慮下能不能用泛型呢？在很多知名框架中都大面積使用泛型，jdk內(nèi)部很多類都使用了泛型，spring框架中也大面積使用泛型。
有個(gè)比較簡(jiǎn)單的判斷該類是否可以用泛型替代的辦法，就是當(dāng)你把類中所有的實(shí)體類都用共同的接口或者Object替換掉，是否可以正常運(yùn)行，如果可以那么就表示這個(gè)類可以用泛型替代，不用重復(fù)寫那么多功能雷同的類。
下面就是一個(gè)泛型的例子，你可以試著看下把其中的E全部換成Object是不是還是能夠完美運(yùn)行。泛型還有很多用法，這里介紹的例子是最簡(jiǎn)單的無(wú)限制泛型，如果對(duì)于泛型類有要求必須是實(shí)現(xiàn)哪個(gè)接口或者繼承自哪個(gè)類的，那么可以用限定泛型<E extends Food>.
public class Stack<E> {
private E[] elements;
private int size;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
@SuppressWarnings("unchecked")
public Stack() {
elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(E e) {
ensureCapacity();
elements[size++] = e;
}
private void ensureCapacity() {
if (elements.length == size)
elements = Arrays.copyOf(elements, 2 * size + 1);
}
public E pop() {
if(size == 0)
throw new EmptyStackException();
E result = elements[--size];
elements[size] = null;
return result;
}
}
