Java 8为什么使用动态代理？

时间：2015-09-22 18:49:06 阅读：305 评论：0 收藏：0 [点我收藏+]

标签：

技术分享

在Java开发中，常常用到动态动态代理，这是Java 1.3版本就已经有的特性，所以应用非常广泛，特别是J2EE的远程调用。今天小编就和大家分享，为什么要使用动态代理及其使用技巧，希望对Java初学者有所帮助。

在J2EE的远程调用中，给定一个抽象接口以及这个接口的具体实现，就可以通过创建两个额外的类来实现这个接口的远程调用了（如，跨JVM）。首先，在源JVM上实现相应的接口，并将调用细节序列化后通过网络传输。然后，在目标JVM上，获取到序列化后的调用的细节，并分配给具体的的类去调用。

如果没有动态代理和反射的话，Java开发者就必须为每个远程接口都提供两个类。而动态代理是运行时产生的类，实现一个或多个接口，接口中每个方法的调用都会自动转换为 java.runtime.InvocationHandler 提供的方法调用：

技术分享

public interface InvocationHandler {

Object invoke(Object proxy, Method method, Object[] args) throws Throwable;

}

InvocationHandler决定如何处理调用，如何在运行时使用方法的有效信息，包括注解、参数类型及方法的返回类型。这样就可以实现一个通用逻辑来定义方法调用的分发。一旦写好了一个InvocationHandler，就可以调用代理类的 handler 来完成所有接口中的方法，而不是为每一个接口写一个单独的实现。

虽然远程调用最近几年里已经没那么受欢迎了，因为开发者需要明白方法调用分发与网络请求发送在语义和失败模式上的本质区别，但是动态代理仍保留在Java语言中。下面我们就来看看动态代理在其他方面的应用。

魔法匹配器

为了能写出简洁的流式测试，可以使用一个“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 来完成逻辑功能的实现。