更深入的理解动态代理——一个真正让我理解动态代理应用价值的示例

网上关于动态代理的示例很多，比如是

接口A    A.java
接口A的实现类  AImpl.Java
创建一个类型为“AImpl”的对象
   AImpl aImpl = new AImpl();
然后创建这个对象基于接口A的代理类对象proxy。
   Proxy.newInstance(...);
将proxy强转为类型A
   A aProxy = (A)proxy;
然后调用aProxy就会调用到aImpl的实现。。。

可能除了强制转换那块需要想一想外，其他的代码看起来也都很好理解，但会产生一个大大的疑问，有什么用呢？

许久以来，一致没有找到合理的答案，直到学习Spring Data JPA，学到底层原理部分。

这需要了解一下Spring Data JPA对动态代理的应用，东西不多，且容我慢慢道来。

使用Spring Data JPA的一种方式是自己创建接口，实现官方提供的JpaRepository接口，然后无需创建实现类，便可以在类中获取到注入的自己接口的对象。代码示例如下：

public interface UserDao extends JpaRepository<User, Integer>{
      // 这个是我们创建的接口
      // 无需为此接口创建实现类
}
// 这是我们的业务逻辑层
public class UserService{
    @Autowired
    UserDao userDao;
    // ....
    // 这里便是对userDao的调用
    // ....
}

上面代码很简单，很好理解，老生常谈地知道“框架为动态的为我们创建了接口实现类”。

这里的动态创建就是用的动态代理。userDao对象是代理类对象无疑，但是如果调用userDao对象的toString方法，就会发现别有洞天。

打印输出userDao.toString()，就会发现这个被代理的对象其实是SimpleJpaRepository类型。

然后，又一个疑问产生了，为什么SimpleJpaRepository类型的代理对象可以注入给UserDao类型变量（强转成UserDao类型）呢？

仔细想来，是这样的，要区分代理对象和被代理对象。

这里被代理对象是SimpleJpaRepository类型，但是代理对象由于实现了UserDao接口，从而代理对象可以强转成UserDao类型。

而且，UserDao由于继承了JpaRepository的方法，所以其方法列表与同样继承了JpaRepository的SimpleJpaRepository完全一致。

所以，其实在userDao对象的方法时，完全可以转嫁成调用SimpleJpaRepository对象的方法。

又因为，SimpleJpaRepository中实现了接口JpaRepository的所有方法，从而在我们无需写实现代码时，整个逻辑也可以完全跑通。

总的来看，通过动态代理，实现了类型的转接，能通过相同的父接口，调用不同的实现类。

这么一分析，对动态代理的的理解就清晰多了。

更进一步，可以将多个接口的实现类代理到一个代理对象上，具体来讲就是自己创建Repository。

比如：现在需要实现的方法在官方的Repository的各个接口和实现类中不存在，现在已经有了UserDao extends JpaReository。

这是先自定义一个Repository，比如叫UserRepository，是一个接口，在这个接口中定义方法，然后做两件事：

①使UserDao接口继承UserRepository，如此一来，原先程序中的userDao对象就有了新定义的方法；

②创建UserRepository的实现类，并且实现类命名需要是UserDao的名字加上Impl即UserDaoImpl（只有这样才能被框架识别，据说是。这么命名肯定可以，其他方式是否支持我没有验证）。

注意不能直接创建UserDao的实现类是因为UserDao接口中定义了大量的方法，并且这些方法都已经被框架实现。