建議106：動態代理可以使代理模式更加靈活
Java的反射框架提供了動態代理(Dynamic Proxy)機制，允許在執行期對目標類生成代理，避免重複開發。我們知道一個靜態代理是通過主題角色(Proxy)和具體主題角色(Real Subject)共同實現主題角色(Subject)的邏輯的，只是代理角色把相關的執行邏輯委託給了具體角色而已，一個簡單的靜態代理如下所示：
interface Subject { // 定義一個方法 public void request(); } // 具體主題角色 class RealSubject implements Subject { // 實現方法 @Override public void request() { // 實現具體業務邏輯 } } class Proxy implements Subject { // 要代理那個實現類 private Subject subject = null; // 預設被代理者 public Proxy() { subject = new RealSubject(); } // 通過建構函式傳遞被代理者 public Proxy(Subject _subject) { subject = _subject; } @Override public void request() { before(); subject.request(); after(); } // 預處理 private void after() { // doSomething } // 善後處理 private void before() { // doSomething } }
這是一個簡單的靜態代理。Java還提供了java.lang.reflect.Proxy用於實現動態代理：只要提供一個抽象主題角色和具體主題角色，就可以動態實現其邏輯的，其例項程式碼如下：
interface Subject { // 定義一個方法 public void request(); } // 具體主題角色 class RealSubject implements Subject { // 實現方法 @Override public void request() { // 實現具體業務邏輯 } } class SubjectHandler implements InvocationHandler { // 被代理的物件 private Subject subject; public SubjectHandler(Subject _subject) { subject = _subject; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 預處理 System.out.println("預處理..."); //直接呼叫被代理的方法 Object obj = method.invoke(subject, args); // 後處理 System.out.println("後處理..."); return obj; } }
注意這裡沒有代理主題角色，取而代之的是SubjectHandler 作為主要的邏輯委託處理，其中invoke方法是介面InvocationHandler定義必須實現的，它完成了對真實方法的呼叫。
我們來詳細解釋一下InvocationHandler介面，動態代理是根據被代理的介面生成的所有方法的，也就是說給定一個或多個介面，動態代理會宣稱“我已經實現該介面下的所有方法了”，那大家想想看，動態代理是怎麼才能實現介面中的方法呢？在預設情況下所有方法的返回值都是空的，是的，雖然代理已經實現了它，但是沒有任何的邏輯含義，那怎麼辦？好辦，通過InvocationHandler介面的實現類來實現，所有的方法都是由該Handler進行處理的，即所有被代理的方法都由InvocationHandler接管實際的處理任務。
我們開看看動態代理的場景，程式碼如下：
public static void main(String[] args) { //具體主題角色，也就是被代理類 Subject subject = new RealSubject(); //代理例項的處理Handler InvocationHandler handler =new SubjectHandler(subject); //當前載入器 ClassLoader cl = subject.getClass().getClassLoader(); //動態代理 Subject proxy = (Subject) Proxy.newProxyInstance(cl,subject.getClass().getInterfaces(),handler); //執行具體主題角色方法 proxy.request(); }
此時就實現了，不用顯式建立代理類即實現代理的功能，例如可以在被代理的角色執行前進行許可權判斷，或者執行後進行資料校驗。
動態代理很容易實現通用的代理類，只要在InvocationHandler的invoke方法中讀取持久化的資料即可實現，而且還能實現動態切入的效果，這也是AOP(Aspect Oriented Programming)變成理念。
建議107：使用反射增加裝飾模式的普適性
裝飾模式(Decorator Pattern)的定義是“動態的給一個物件新增一些額外的職責。就增加功能來說，裝飾模式相比於生成子類更為靈活”，不過，使用Java的動態代理也可以實現裝飾模式的效果，而且其靈活性、適應性都會更強。
我們以卡通片《貓和老鼠》(Tom and Jerry)為例，看看如何包裝小Jerry讓它更強大。首先定義Jerry的類：老鼠（Rat類），程式碼如下：
interface Animal{ public void doStuff(); } class Rat implements Animal{ @Override public void doStuff() { System.out.println("Jerry will play with Tom ......"); } }
接下來，我們要給Jerry增加一些能力，比如飛行，鑽地等能力，當然使用繼承也很容易實現，但我們這裡只是臨時的為Rat類增加這些能力，使用裝飾模式更符合此處的場景，首先定義裝飾類，程式碼如下：
//定義某種能力 interface Feature{ //載入特性 public void load(); } //飛行能力 class FlyFeature implements Feature{ @Override public void load() { System.out.println("增加一對翅膀..."); } } //鑽地能力 class DigFeature implements Feature{ @Override public void load() { System.out.println("增加鑽地能力..."); } }
此處定義了兩種能力：一種是飛行，另一種是鑽地，我們如果把這兩種屬性賦予到Jerry身上，那就需要一個包裝動作類了，程式碼如下：
class DecorateAnimal implements Animal { // 被包裝的動物 private Animal animal; // 使用哪一個包裝器 private Class<? extends Feature> clz; public DecorateAnimal(Animal _animal, Class<? extends Feature> _clz) { animal = _animal; clz = _clz; } @Override public void doStuff() { InvocationHandler handler = new InvocationHandler() { // 具體包裝行為 @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object obj = null; if (Modifier.isPublic(method.getModifiers())) { obj = method.invoke(clz.newInstance(), args); } animal.doStuff(); return obj; } }; //當前載入器 ClassLoader cl = getClass().getClassLoader(); //動態代理，又handler決定如何包裝 Feature proxy = (Feature) Proxy.newProxyInstance(cl, clz.getInterfaces(), handler); proxy.load(); } }
注意看doStuff方法，一個裝飾型別必然是抽象構建(Component)的子型別，它必須實現doStuff方法，此處的doStuff方法委託給了動態代理執行，並且在動態代理的控制器Handler中還設定了決定裝飾方式和行為的條件(即程式碼中InvocationHandler匿名類中的if判斷語句)，當然，此處也可以通過讀取持久化資料的方式進行判斷，這樣就更加靈活了。
抽象構建有了，裝飾類也有了，裝飾動作類也完成了，那我們就可以編寫客戶端進行呼叫了，程式碼如下：
public static void main(String[] args) { //定義Jerry這隻老鼠 Animal jerry = new Rat(); //為Jerry增加飛行能力 jerry = new DecorateAnimal(jerry, FlyFeature.class); //jerry增加挖掘能力 jerry = new DecorateAnimal(jerry, DigFeature.class); //Jerry開始戲弄毛了 jerry.doStuff(); }
此類程式碼只一個比較通用的裝飾模式，只需要定義被裝飾的類及裝飾類即可，裝飾行為由動態代理實現，實現了對裝飾類和被裝飾類的完全解耦，提供了系統的擴充套件性。
建議108：反射讓模板方法模式更強大
模板方法模式(Template Method Pattern)的定義是：定義一個操作中的演算法骨架，將一些步驟延遲到子類中，使子類不改變一個演算法的結構即可重定義該演算法的某些特定步驟。簡單的說，就是父類定義抽象模板作為骨架，其中包括基本方法(是由子類實現的方法，並且在模板方法中被呼叫)和模板方法（實現對基本方法的排程，完成固定的邏輯），它是用了簡單的繼承和覆寫機制，我麼來看一個基本的例子。
我們經常會開發一些測試或演示程式，期望系統在啟動時自動初始化，以方便測試或講解，一般的做法是寫一個SQL檔案，在系統啟動前自動匯入，不過，這樣不僅麻煩而且容易出錯，於是我們就手寫了一個自動初始化資料的框架：在系統（或容器）自動啟動時自行初始化資料。但問題是每個應用程式要初始化的內容我們並不知道，只能由實現者自行編寫，那我們就必須給作者預留介面，此時就得考慮使用模板方法模式了，程式碼如下：
1 public abstract class AbsPopulator { 2 // 模板方法 3 public final void dataInitialing() throws Exception { 4 // 呼叫基本方法 5 doInit(); 6 } 7 8 // 基本方法 9 protected abstract void doInit(); 10 }
這裡定義了一個抽象模板類AbsPopulator，它負責資料初始化，但是具體要初始化哪些資料則是由doInit方法決定的，這是一個抽象方法，子類必須實現，我們來看一個使用者表資料的載入：
public class UserPopulator extends AbsPopulator{ @Override protected void doInit() { //初始化使用者表，如建立、載入資料等 } }
該系統在啟動時查詢所有的AbsPopulator實現類，然後dataInitialing實現資料的初始化。那大家可能要想了，怎麼讓容器指導這個AbsPopulator類呢？很簡單，如果是使用Spring作為Ioc容器的專案，直接在dataInitialing方法上加上@PostConstruct註解，Spring容器啟動完畢後自動執行dataInitialing方法。具體大家看spring的相關知識，這裡不再贅述。
現在問題是：初始化一張User表需要非常多的操作，比如先建表，然後篩選資料，之後插入，最後校驗，如果把這些都放入到一個doInit方法裡會非常龐大(即使提煉出多個方法承擔不同的責任，程式碼的可讀性依然很差)，那該如何做呢？又或者doInit是沒有任何的也無意義的，是否可以起一個優雅而又動聽的名字呢？
答案是我們可以使用反射增強模板方法模式，使模板方法實現對一批固定的規則的基本方法的呼叫。程式碼是最好的交流語言，我們看看怎麼改造AbsPopulator類，程式碼如下：
public abstract class AbsPopulator { // 模板方法 public final void dataInitialing() throws Exception { // 獲得所有的public方法 Method[] methods = getClass().getMethods(); for (Method m : methods) { // 判斷是否是資料初始化方法 if (isInitDataMethod(m)) { m.invoke(this); } } } // 判斷是否是資料初始化方法，基本方法鑑定器 private boolean isInitDataMethod(Method m) { return m.getName().startsWith("init")// init開始 && Modifier.isPublic(m.getModifiers())// 公開方法 && m.getReturnType().equals(Void.TYPE)// 返回值是void && !m.isVarArgs()// 輸出引數為空 && !Modifier.isAbstract(m.getModifiers());// 不能是抽象方法 } }
在一般的模板方法模式中，抽象模板(這裡是AbsPopulator類)需要定義一系列的基本方法，一般都是protected訪問級別的，並且是抽象方法，這標誌著子類必須實現這些基本方法，這對子類來說既是一個約束也是一個負擔。但是使用了反射後，不需要定義任何抽象方法，只需要定義一個基本方法鑑定器(例子中的isInitDataMethod)即可載入符合規則的基本方法。鑑別器在此處的作用是鑑別子類方法中哪些是基本方法，模板方法(例子中的dataInitaling)則需要基本方法鑑定器返回的結果通過反射執行相應的方法。
此時，如果需要進行大量的初始化工作，子類的實現就非常簡單了，程式碼如下：
public class UserPopulator extends AbsPopulator { public void initUser() { /* 初始化使用者表，如建立、載入資料等 */ } public void initPassword() { /* 初始化密碼 */ } public void initJobs() { /* 初始化工作任務 */ } }
UserPopulator類中的方法只要符合基本方法鑑別器條件即會被模板方法呼叫，方法的資料量也不再受父類的約束，實現了子類靈活定義基本方法、父類批量呼叫的功能，並且縮減了子類的程式碼量。
如果大家熟悉JUnit的話，就會看出此處的實現與JUnit非常相似，JUnit4之前要求測試的方法名必須是以test開頭的，並且無返回值、無引數，而且是public修飾，其實現的原理與此非常類似，大家有興趣可以看看Junit的原始碼。
建議109：不需要太多關注反射效率
反射的效率是一個老生常談的問題，有"經驗" 的開發人員經常會使用這句話恐嚇新人：反射的效率是非常低的，不到萬不得已就不要使用。事實上，這句話前半句是對的，後半句是錯的。
反射的效率相對於正常的程式碼執行確實低很多，但它是一個非常有效的執行期工具類，只要程式碼結構清晰、可讀性好那就先開發起來，等到進行效能測試時證明此處效能確實有問題再修改也不遲(一般情況下，反射並不是效能的終極殺手，而程式碼結構混亂、可讀性差則可能會埋下效能隱患)。我們看這樣一個例子，在執行期獲得泛型類的泛型，程式碼如下：
class Utils { // 獲得一個泛型類的實際泛型型別 public static <T> Class<T> getGenricClassType(Class clz) { Type type = clz.getGenericSuperclass(); if (type instanceof ParameterizedType) { ParameterizedType pt = (ParameterizedType) type; Type[] types = pt.getActualTypeArguments(); if (types.length > 0 && types[0] instanceof Class) { // 若有多個泛型引數，依據位置索引返回 return (Class<T>) types[0]; } } return (Class<T>) Object.class; } }
前面我們講過，Java泛型只存在於編譯器，那為什麼這個工具類可以取得執行期的泛型型別呢?那是因為該工具只支援繼承的泛型類，如果是在Java編譯時已經確定了泛型類的型別引數，那當然可以通過泛型類獲得了。例如有這樣一個泛型類：
abstract class BaseDao<T>{ //獲得T執行期的型別 private Class<T> clz = Utils.getGenricClassType(getClass()); //根據主鍵獲得一條記錄 public void get(long id){ session.get(clz,id); } } //操作user表 class UserDao extends BaseDao<String>{ }
對於UserDao類，編譯器編譯時已經明確了其引數型別是String，因此可以通過反射的方式來獲取其型別，這也是getGenricClassType方法使用的場景。
BaseDao和UserDao是ORM中的常客，BaseDao實現對資料庫的基本操作，比如增刪改查，而UserDao則是一個比較具體的資料庫操作，其作用是對User表進行操作，如果BaseDao能夠提供足夠多的基本方法，比如單表的增刪改查，哪些與UserDao類似的BaseDao子類就可以省卻大量的開發工作。但問題是持久層的session物件(這裡模擬的是Hibernate Session)需要明確一個具體的型別才能操作，比如get查詢，需要獲得兩個引數：實體類型別(用於確定對映的資料表)和主鍵，主鍵好辦，問題是實體類型別怎麼獲得呢？
子類進行傳遞?麻煩，而且也容易產生錯誤。
讀取配置問題？可行，但效率不高。
最好的辦法就是父類泛型化，子類明確泛型引數，然後通過反射讀取相應的型別即可，於是就有了我們程式碼中clz變數：通過反射獲得泛型型別。如此實現後，UserDao可不用定義任何方法，繼承過來的父類操作方法已經滿足基本需求了，這樣的程式碼結構清晰，可讀性又好。
想想看，如果考慮反射效率問題，沒有clz變數，不使用反射，每個BaseDao的子類都要實現一個查詢操作，程式碼將會大量重複，違反了" Don't Repeat Yourself " 這條最基本的編碼規則，這會致使專案重構、優化難度加大，程式碼的複雜度也會提高很多。
對於反射效率的問題，不要做任何的提前優化和預期，這基本上是杞人憂天，很少有專案是因為反射問題引起系統效率故障的（除非是拷貝的垃圾程式碼），而且根據二八原則，80%的效能消耗在20%的程式碼上，這20%的程式碼才是我們關注的重點，不要單單把反射作為重點關注物件。
注意：反射效率低是個真命題，但因為這一點而不使用它就是個假命題。