AOP核心思想

AOP核心思想

AOP原理：
动态代理技术。
详解：
静态代理，场景如下：
以玩家玩游戏为例，登入，打怪，升级。可以写个玩家类，里面对应这三个方法。但能不能更优秀一点呢？ 玩家懒了不想自己打还想升级，那么就找代练。走个代理玩家类，定义一个玩家类属性，并且在构造方法里实例化玩家类这个对象，并且使用和玩家一样的方法（登入，打怪，升级）。Ps：其实这个代练稍微有点不恰当，玩家还是最苦逼的角色，因为依然是执行方法的主体。这时候就可以使用代理玩家类来打游戏，嗯，感觉是牛B了。
当然，代练也有自己的个性，什么个性呢，废话不要联系玩家吗？不要事后收费吗？也就是befor登入，after升级可以有这两个方法。总结就是：代理可以替被代理人做所有事（表面做事，恶心的一批），同事也可以有自己的个性（谋取利润）。想想真黑啊。
静态代理便是如此，有个不好的，是啥呢？就是有个玩家就要有个玩家代练，还要完成玩家的所有方法，感觉这代练公司也不赚啊~

那么jdk爸爸1.3版本之后便给了我们动态代理的方法，代理类实现InvacationHandle接口，主要使用invoke的反射机制方法，使用代理的时候可传入哪个对象就创建哪个对象的代理，并添加自己的before/after方法。这样厉害了吧，代练公司又赚了，人力资源管理成本下降了，进入机器人代练模式。 （代码怎么实现的自己研究）

这时候代练公司还不满足，不满足在哪里呢？不想代练在升级后收费了，想在联系玩家时候收费（有点黑，跑路咋办），这时候因为代理自己的方法是耦合在代理类里面的，不好管理。嗯，得想办法解耦，这样便于自己控制时机，想什么时候收费什么时候收费。这时候就创建一个接口，叫做代练手段，里面就有before和after方法（before收费或者after收费看代练公司心情）；并且创建其实现类。依然在代理类中用反射的方法（getDeclaredMethod）去执行方法，嗯，，，这样哪天代练公司不想收费了，变成付费了只需要修改实现类的方法就好了。
补充一点：这种思想其实就是设计模式里面的桥梁模式，重在细化颗粒度以解耦。

这样其实一个AOP就已经手写完成了。

核心思想：代理模式+桥梁模式+SRP原则

随便写写，不喜勿喷。