前言
這是Java Rules系列的第二篇, 繼續(xù)介紹一些規(guī)則和技巧。
1. 多用組合少用繼承
這個(gè)規(guī)則其實(shí)在很多書(shū)中都提到過(guò)羊赵，在《重構(gòu)》這本書(shū)中也有一個(gè)章節(jié)詳細(xì)描述了原因潮梯，總結(jié)下來(lái)主要就是因?yàn)樽宇?lèi)依賴(lài)于超類(lèi)中的特定功能，超類(lèi)可能隨著不斷迭代艘策，功能內(nèi)容有所修改，但是子類(lèi)是繼承自超類(lèi)的渊季，如果超類(lèi)的基礎(chǔ)功能發(fā)生變化朋蔫，那么子類(lèi)在代碼完全沒(méi)有變化的情況下罚渐，可能功能也發(fā)生了變化，產(chǎn)生了變化傳導(dǎo)效應(yīng)驯妄，對(duì)于分析問(wèn)題和代碼閱讀可能都會(huì)存在不好的影響荷并。而且寫(xiě)過(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è)類(lèi)針對(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)肯定是沒(méi)問(wèn)題的磅甩，但是當(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)類(lèi)HttpClientImp類(lèi)谭梗，這個(gè)類(lèi)基于httpclient實(shí)現(xiàn)了NetWorkClient接口中的get和post方法忘晤，在調(diào)用模塊中直接調(diào)用NetWorkClient接口的get或者post方法，那么對(duì)于調(diào)用模塊來(lái)說(shuō)默辨，它不知道后面的具體實(shí)現(xiàn)是哪個(gè)類(lèi)德频，但是接口請(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)求類(lèi)就可以了表谊，調(diào)用模塊里的方法完全不用修改，可以做到完全無(wú)感知替換底層網(wǎng)絡(luò)實(shí)現(xiàn)盖喷。
3. 集合類(lèi)一定不要使用原始類(lèi)
我們?cè)诰幋a過(guò)程中經(jīng)常會(huì)用到集合類(lèi)爆办，例如List、HashMap课梳、Queue等距辆，這些集合類(lèi)java是允許直接定義、直接使用的暮刃，例如List list = new ArrayList();但是對(duì)于初始化出來(lái)的list跨算，我們可以隨便add對(duì)象進(jìn)去，因?yàn)榧项?lèi)默認(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集合類(lèi)對(duì)象的時(shí)候背犯，最好指定好泛型List<String> list = new ArrayList<String>();，這樣在編譯階段誤插的對(duì)象如果類(lèi)型不對(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è)谌粘ｉ_(kāi)發(fā)過(guò)程中經(jīng)常遇到一些看起來(lái)差不多的類(lèi)丛晦，處理邏輯都是一樣奕纫，只是針對(duì)的對(duì)象不同，這個(gè)時(shí)候我們就應(yīng)該要考慮下能不能用泛型呢烫沙？在很多知名框架中都大面積使用泛型匹层，jdk內(nèi)部很多類(lèi)都使用了泛型，spring框架中也大面積使用泛型。
有個(gè)比較簡(jiǎn)單的判斷該類(lèi)是否可以用泛型替代的辦法升筏，就是當(dāng)你把類(lèi)中所有的實(shí)體類(lèi)都用共同的接口或者Object替換掉撑柔，是否可以正常運(yùn)行，如果可以那么就表示這個(gè)類(lèi)可以用泛型替代您访，不用重復(fù)寫(xiě)那么多功能雷同的類(lèi)铅忿。
下面就是一個(gè)泛型的例子，你可以試著看下把其中的E全部換成Object是不是還是能夠完美運(yùn)行灵汪。泛型還有很多用法檀训，這里介紹的例子是最簡(jiǎn)單的無(wú)限制泛型，如果對(duì)于泛型類(lèi)有要求必須是實(shí)現(xiàn)哪個(gè)接口或者繼承自哪個(gè)類(lèi)的享言，那么可以用限定泛型<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;
}
}
