Java 8 動態代理的新技巧：為什么使用動態代理？
動態代理（Dynamic proxies）是 Java 1.3 引入的特性，在 J2EE 的遠程調用中應用非常廣泛。給定一個抽象接口以及這個接口的具體實現，就可以通過創建兩個額外的類來實現這個接口的遠程調用了（如，跨JVM）。首先，在 源JVM上實現相應的接口，并將調用細節序列化后通過網絡傳輸。然后，在目標JVM上，獲取到序列化后的調用的細節，并分配給具體的的類去調用。
沒有動態代理和反射，開發者不得不為每個遠程接口提供兩個類。一個動態代理是運行時產生的類，實現一個或多個接口，接口中每個方法的調用都會自動轉換為 java.runtime.InvocationHandler 提供的方法調用：
- public interface InvocationHandler {
- Object invoke(Object proxy, Method method, Object[] args) throws Throwable;
- }
InvocationHandler決定如何處理調用，如何在運行時使用方法的有效信息，包括注解、參數類型及方法的返回類型。這樣就可以實現一個 通用邏輯來定義方法調用的分發。一旦你寫好了一個InvocationHandler，就可以調用代理類的 handler 來完成所有接口中的方法，而不是為每一個接口寫一個單獨的實現。
遠程調用最近幾年里已經沒那么受歡迎了，因為開發者需要明白方法調用分發與網絡請求發送在語義和失敗模式上的本質區別，但是動態代理仍保留在語言當 中。在這篇文章中，我將討論動態代理其他方面的作用。在下一篇文章中，將討論動態代理新的實現技術，這些技術是由于 Java 8 引入 lambda 表達式和默認方法而產生的。
魔法匹配器
這些年來，我一直在使用一個“Magic” 對象，以便能夠寫出簡潔的流式測試。我定義了一個“magic”的接口，然后通過一個動態代理來實現目標行為。比較特別的是，在測試時候用”magic builders”來生成測試值，然后用“magic matchers”來表述斷言屬性測試的結果。我們這里只關注匹配器。
我們有一個Person支撐類，這是一個典型的bean——成員變量是私有的，通過getter和setter方法暴露。
- public class Person {
- private String name;
- private int age;
- // insert getters and setters here
- }
使用一個簡單Hamcrest類，我們有兩種方式來斷言該類的實例。一種方法是單獨抽取每個值，分開斷言。
- assertThat(person.getName(), containsString("Smith"));
- assertThat(person.getAge(), greaterThan(30));
另一種方式是使用allOf和hasProperty方法，將對象作為一個整體，通過一組期望值來匹配。
- assertThat(person, allOf(
- hasProperty("name", containsString("Smith")),
- hasProperty("age", greaterThan(30)));
這樣能很好的工作，但是這種方式對 Hamcrest 描述整體匹配和錯誤匹配并沒有什么幫助。
- Expected: (hasProperty("name", a string containing "Putey") and hasProperty("age", a value greater than <43>))
- but: hasProperty("age", a value greater than <43>) property 'age' <42> was less than <43>
hasProperty的匹配在類型一致性的檢測也是非常弱的：我們可以寫成 hasProperty(“age”, containsString(“Smith”))，這樣類型檢測也不會拒絕。
我們真正想要的是一個流式API，能夠像下面一樣使用：
- assertThat(person, aPerson()
- .withName("Arthur Putey")
- .withAge(greaterThan(43)));
并且能夠很好且易于理解地報告錯誤的匹配：
- Expected:
- name: a string containing "Putey"
- age: a value greater than <43>
- but:
- age: <42> was less than <43>
很容易寫一個上述功能的自定義匹配器，但是不得不很乏味地寫很多次。幸運的是，可以通過動態代理來幫我們解決。首先，我們定義一個流式接口，該接口包含如下方法：
- interface PersonMatcher extends Matcher<Person> {
- PersonMatcher withName(String expected);
- PersonMatcher withName(Matcher<? super String> matching);
- PersonMatcher withAge(int expected);
- PersonMatcher withAge(Matcher<Integer> matching);
- }
然后，我們使用在一個名為 MagicMatcher 的類上的靜態方法來獲取動態代理，該代理實現了這個接口，然后通過方法調用來獲取調節表達式：
- static PersonMatcher aPerson() {
- return MagicMatcher.proxying(PersonMatcher.class);
- }
每個方法的調用都通過代理類的“interpreted”方法來實現，該代理從方法（“withAge”）中獲取屬性（“age”），并指定調用匹 配對象上的（“getAge”）方法來獲取屬性值。屬性的名稱以及匹配中對應的值將會被存儲，直到代理類的 match 或 describeMismatch 方法被調用（這就是為什么接口需要繼承 Matcher）。在調用的時候需要抽取并測試對象的屬性，如果有必要，會創建錯誤匹配報告。
這種方式是輕量級的，我們可以引入任何新的自定義的接口，并在測試中重用，這樣，是非常有利于編寫自定義Hamcrest匹配器的，因為不再需要編 寫接口的實現。所有需要生成的在接口中定義的匹配器行為，都只需要實現一次，我們通過一個合適的 InvocationHandler 來完成邏輯功能的實現。
下一篇文章中，我將創建一個很小的，但是很有用的庫，我們使用 Java 8 的動態代理來完成各項功能，并演示一些用于實現各種代理行為的方式，包括接口及”magic”對象的生成。這個庫的源代碼，包括這篇文章中討論的 MagicMatcher 類的實現，都可以在 github 上找到。
