旧欢新梦里，不觉行路难
翻以前的博客，上一次提到aop还是两年前的大学时期初学切面时写的，当时遇到的那个问题在今天看来毫无疑问只能用愚蠢来形容。不过，至少证明了这两年来在技术上还是成长了不少。这一篇，我想还是按照两年前那一篇的写法来完成。
最近在公司写一个新项目，里面需要对返回值进行权限管控，剔除掉其中不满足权限要求的数据。作为一个各接口都需要的横向功能，自然会想到使用aop来完成，通常想到的做法就是工具类+注解+aop这一套。本来是没有什么问题的，但是因为是和另一个同事共同开发，两人在接口返回格式上没有统一，我的接口因为有一些额外数据多封装了一层。所以我的想法是为了统一处理，在我自己代码的service层封装数据时抽出一个方法处理这种结构的数据，然后在这个额外的方法上完成切面操作。
service层中的实现：
@Override
public ComplexObject dosomething(){
...
complexObject.setList(handleList(xxList));
return complexObject;
}
@Authority
private <T> List<T> handleList(T list){
...
return afterHandleList;
}为了更加直观的表述，写了段在结构上类似的伪代码来作为说明。
但是事情并不如意，切面在这个代码结构下并不生效，执行了handleList方法却没有进入切面执行。之后尝试了改可见范围private为public，依然不可行。这时候就意识到问题可能是由于对于的aop实现原理理解不到位而导致的。赶紧翻出aop实现的相关介绍恶补一下。
spring aop动态代理由JDK动态代理和CGLIB动态代理两种方式共同实现。
很多文章其实都有在很详细的讲这两种动态代理方式实现的具体细节，而这不是解决这个问题要关注的重点，所以只是稍微介绍一下两种动态代理实现代码增强的方式。
- JDK动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler来处理。
- CGLIB动态代理是利用asm开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。
而spring aop根据场景的不同，自动在两种方法之间选择执行。实现了接口的情况下优先选择使用JDK动态代理的方式，也可以手动指定使用CGLIB的方式，没有实现接口的情况只能使用CGLIB。所以显然我们这个场景下是CGLIB的动态代理实现，根据调试的信息$$EnhancerBySpringCGLIB也能验证这个结论。
spring aop代理由ioc容器负责生成和管理，依赖关系也是ioc容器负责。因此aop代理可以直接使用容器中的其他bean实例作为目标，这种关系可由ioc容器的依赖注入提供。
所以将目光只关注在cglib上，这里有一个重点，cglib是通过对字节码的修改并生成子类的方式来实现代码的增强，而aop会通过ioc来对这些生成的子类进行注入。
困惑的问题就这么被一句话解决了，之前自己的理解是动态代理是通过对原对象的class文件修改实现功能的加强，而实际上是生成了一个实现了功能增强的子类，在调用方法的类中将外部的注入对象由原来的类替换成了这个子类。
这下问题就得到了解释，同一个类中方法调用无法触发增强逻辑，是因为这时调用的是这个类的方法，并没有成功调用到代理类中的方法。作为对这个解释的验证，我们可以通过AopContext.currentProxy()获取到当前类的代理类，然后调用相应的方法就可以了。
private MyService getService(){
// 采取这种方式的话，
//@EnableAspectJAutoProxy(exposeProxy=true,proxyTargetClass=true)
//必须设置为true
return AopContext.currentProxy() != null ? (MyService)AopContext.currentProxy() : this;
}同时也解答了另外一个问题，标记为final的方法不能够被代理，因为final方法无法通过子类进行重写。同样private类型的方法，因为没有办法被外部调用，所以也无法通过动态代理来增强。
正文就到此结束了。以下是感想部分。
最初是没有打算写这一篇的，因为这个问题其实蛮简单的，这种问题都要去想半天才解决，看上去就是很菜的样子。不过在这个过程中，想起了两年前刚跑到公司实习，天天没事做就在那自己找东西看的日子，所以想留个纪念，不管是看起来有成长也好，看起来还是那样也好，至少在未来的某一天，也许是遇到aop的另外一个问题时，能够回想起今天的自己。篇首的引用其实来源于两首诗，被我牵强附会合并在一起用了。
