[[286584]]

一、泛型介紹

在日常編程的過程中，泛型在這三個特性之中使用頻率是最高的。”泛型”一詞中的泛字可以理解為泛化的意思，即由具體的、個別的擴大為一般的。Oracle對泛型的官方定義是：泛型類型是通過類型參數化的泛型類或接口。一言以蔽之，泛型就是通過類型參數化，來解決程序的通用性設計和實現的若干問題。

Java泛型是1.5版本后引入的特性，它主要被用于解決三類問題：

1、編譯器類型檢查

例如上圖中的實例1設計了一個簡單的Box類，在其中定義了一個private的object的屬性，同時定義了get()和set()兩個行為，其中set()用于保存object到Box內，set()用于獲取Box中的object對象。從抽象的角度看，Box類抽象了一個用于在盒子中存放物品對象和存取的行為，存取的方法接受或者返回Object類型的對象。在這個抽象的基礎上，可以存放除原始類型外任意類型的對象，Object類型的聲明體現了面向對象中繼承的理念。

在實例2中，實現了不同業務場景下對Box的使用方式。其中列舉了兩種不同的業務場景，場景一需要在Box中存放String類型的對象，場景二需要在Box中存放Integer類型的對象，這種情況下，在實際開發時，場景二中很有可能會錯誤地傳入一個String對象，導致運行時錯誤的發生，而這正是因為Box可以被只有傳入任意類型的對象導致的，這種情況在集合類操作時尤為突出。例如實例3中的情況：

首先聲明了一個List類型的boxes對象，其中存放了兩個對象，一個是String類型的“aaaaa”，另一個是Integer類型的11111。在業務場景一下，使用者認為boxes中存放的所有對象都是String類型的，因此在取出第二個對象并進行類型轉換的時候就發生了錯誤。這種情況往往讓使用者十分迷惑，明明編譯時沒有問題，但是在運行時卻產生了異常。也就是說，在這種面向對象的抽象過程中，無法通過編譯來驗證類型該如何進行使用。

那么泛型是如何解決這類問題的呢？

Oracle意識到了上述的問題，在引入泛型之后，通過將代碼中的“public class Box”更改為“public class Box<T>”來創建泛型類型的聲明，而這個聲明的背后實質上是引入了可以在類中任何地方使用的類型變量T。如實例4中所示：可以看到，除了新增的泛型類型聲明<T>外，所有在原來代碼中出現的Object都被類型變量T所替換。

乍一看類型變量這個詞，感覺有點晦澀難懂，但其實如果仔細思量一番會發現它其實并不難理解，上面的實例4可以理解為“在使用泛型時，可以將類型參數T傳遞給Box類型本身”，結合Oracle給出的官方定義“泛型的本質是類型參數化”會有更深的理解。

在實例5中，在對象聲明和初始化的時候，都指定了類型參數T，在場景一種，T為String；在場景二中，T為Integer。這樣，在場景二中向IntegerBox中傳入String類型的數據“aaaaa”時，程序會報錯。實例6中的泛型集合對象的操作也與之類似，在聲明了一個List<String>的boxes對象之后，如果向boxes中傳入Integer對象11111，程序會報錯。

可以看到，通過對于泛型的使用，之前的多業務場景中的問題都得到了解決，因為現在在編譯階段就可以解決之前類型不匹配的問題，而不用等到運行時才暴露問題，只要合理使用泛型，就能在很大程度上規避此類風險。對于泛型的使用，這種參數化類型的作用表面上看是聲明，背后其實是約定。

2、強制類型轉換

再回顧一下實例3，在List類型的boxes對象中存放了兩個對象，分別是String類型的“aaaaa”和Integer類型的11111。其中存在一個問題，在對于boxes的聲明中，使用者不知道boxes的list中到底應該存放什么類型的對象，而編譯器也不知道集合存放的數據類型，只能通過實際的業務場景來決定這個box是什么類型，采用將Object強制轉換成String的方式，來達到業務要求的效果。

在使用泛型之后，解決了這種場景下必須進行強制類型轉換的問題。如實例7中，通過泛型聲明，指定集合內元素的類型參數為String類型，這樣編譯器就直接知曉了元素的類型，而無需依靠實際的業務邏輯進行轉換，從而解決了這類類型強制轉換的問題。

3、可讀性和靈活性

泛型除了能進行編譯器類型檢查和規避類型強制轉換外，還能有效地提高代碼的可讀性。對于實例3，如果不使用泛型，當一個不清楚業務場景的人在對集合進行操作時，無法知道list中存儲的是什么類型的對象，如果使用了泛型，就能夠通過其類型參數判斷出當前的業務場景，也增加了代碼的可讀性，同時也可以大膽地在抽象繼承的基礎上進行開發了。

泛型使用上的靈活性體現在很多方面，因為它本身實質上就是對于繼承在使用上的一種增強。因為泛型在具體工作時，當編譯器在編譯源碼的時候，首先要進行泛型類型參數的檢查，檢查出類型不匹配等問題，然后進行類型擦除并同時在類型參數出現的位置插入強制轉換指令，從而實現泛型。

除了上述的基礎用法之外，泛型還有幾種特殊的高階用法：

通配符的設計存在一定的場景，例如在使用泛型后，首先聲明了一個Animal的類，而后聲明了一個繼承自Animal類的Cat類，顯然Cat類是Animal類的子類，但是List<Cat>卻不是List<Animal>的子類型，而在程序中往往需要表達這樣的邏輯關系。為了解決這種類似的場景，在泛型的參數類型的基礎上新增了通配符的用法，具體來說有三種用法：<? extends T>、<? super T>、<?>。其中前兩者被稱為限定通配符，<?>被稱為非限定通配符。

1、<? extends T> 上界通配符

上界通配符顧名思義，<? extends T>表示的是類型的上界（包含自身），因此通配的參數化類型可能是T或T的子類。正因為無法確定具體的類型是什么，add方法受限（可以添加null，因為null表示任何類型），但可以從列表中獲取元素后賦值給父類型。如上圖中的第一個例子，第三個add()操作會受限，原因在于List<Animal>和List<Cat>是List<? extends Animal>的子類型。

2、<? super T> 下界通配符

下界通配符<? super T>表示的是參數化類型是T的超類型（包含自身），層層至上，直至Object，編譯器無從判斷get()返回的對象的類型是什么，因此get()方法受限。但是可以進行add()方法，add()方法可以添加T類型和T類型的子類型，如第二個例子中首先添加了一個Cat類型對象，然后添加了兩個Cat子類類型的對象，這種方法是可行的，但是如果添加一個Animal類型的對象，顯然將繼承的關系弄反了，是不可行的。

3、<?> 無界通配符

在理解了上界通配符和下界通配符之后，其實也自然而然的理解了無界通配符。無界通配符用<?>表示，?代表了任何的一種類型，能代表任何一種類型的只有null（Object本身也算是一種類型，但卻不能代表任何一種類型，所以List<Object>和List<null>的含義是不同的，前者類型是Object，也就是繼承樹的最上層，而后者的類型完全是未知的）。

二、反射機制

反射是Java語言本身具備的一個重要的動態機制。用一句話來解釋反射的定義：自控制，自描述。即通過反射可以動態的獲取類、屬性、方法的信息，也能構造對象并控制對象的屬性和行為。

上圖中有一個Apple類，它有兩個構造器、一個屬性和get()、set()兩個行為。在左側的“自描述”中主要是嘗試在動態的過程中借助反射獲取Apple類的構造器信息和對應的參數個數、類的屬性信息和類的方法信息。其中有一個Class類型，它可以產生Class對象被ClassLoader加載，從而在jvm中實現對它的調用。在這段程序中，打印了一些類的信息、類的屬性信息和類的方法信息。在右側的“自控制”的代碼中，實現了在運行的過程中創建了一些對象并觸發這個對象的一些行為，最后還嘗試對對象的屬性進行賦值。反射的基本使用方法較為簡單，但是這種機制卻增強了Java語言的靈活性。

如上圖所示，非反射的Java類的大致運行流程是：編寫源文件Apple.java，然后編譯器將其編譯成字節碼文件Apple.class，最后加載到jvm中并運行。而采用反射的方式時，編譯器一開始對其類型（編譯類型和動態類型）是一無所知的，只有在運行過后，編譯器才知道其真正的類型。

反射的優勢主要在于兩點：

在一些場景中，這種“未知類型”實際上大大增強了程序運行時的靈活性，但是其性能會有一些損耗；

對于對象的類型可以在運行時判斷，這樣的特性實質上是對多態極大地增強，進一步地將上層的抽象與下層的具體實現進行解耦。

這兩點在JDBC Driver中體現的非常明顯，例如上圖中的實例中，JDBC的驅動加載方式是通過反射機制實現的，從而保證運行時可以動態選擇要加載的驅動程序，程序靈活性大大增強。另外，JDBC只是設計了驅動需要實現的接口，并不關心驅動廠商的個數和實現方式，只要安裝統一的規范即可，至于類型的判斷和具體方法的觸發，交給運行期動態判斷即可，這種反射機制的使用淋漓盡致的體現了多態，并且降低了類與類之間的耦合度。

三、注解的使用

注解是在1.5版本引入的，現在已經成為日常程序開發中非常重要的一部分。注解是一種元數據，本身沒有任何作用，如果要有，必須依附在具體的對象上，在日常使用中最常見的兩個注解是@Override和@Deprecated。

先不考慮注解具體的概念、用法和如何工作等問題，注解與“標簽”的概念十分相似，@Override可以理解為在方法上添加了一個標簽，其代表的就是“這是一個繼承關系中，子類已經重寫的方法。”更進一步理解，這個標簽在某個方法上加上之后，如果父類中沒有該方法，那么在編譯的時候就會報錯，而且可以解決在繼承場景下一些不留心將方法名拼錯的情況，同時增強了一些程序的可讀性。

如上圖所示，同樣以@Override為例，對注解進行進一步的提取和抽象。具體抽象出了四個方面：首先在作用域方面，它只能作用于子類重寫的方法上；其次在生命周期方面，注解只是在編譯時進行檢查，在編譯結束后便沒有了任何作用；除此之外，在文檔支持方面，為例解決可讀性的問題，設計了@Documented的注解，用來表示注解的說明注釋是否包含在JavaDoc中；在層級結構設計方面，設計了@inherited用來表示注解是否可以被子類繼承。

在上圖中定義了一個蘋果描述注解，包含了@Target、@Retention、@Inherited和@Documented四個注解，表示它生命周期是程序運行的聲明周期、可以被子類繼承、文檔可以被包含。在設計出這個注解之后，可以將其用在前文中的Apple實例上，如圖中在類和方法上各添加了一個注解，在添加完后，便可以配合反射看到注解的效果，這樣可以更好的加強其自描述的能力和配置的靈活性。