谈谈对AOP的认识三——优化AOP，进一步解耦

有了前两篇博客的铺垫，我们对AOP已经不陌生了。那么，AOP，你了解了有多少呢？
都知道AOP（Aspect-Oriented Programming，面向方面编程）是OOP（Object-Oriented Programing，面向对象编程）的补充和完善。AOP利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块，并将其名为
“Aspect”，即方面。所谓“方面”，简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。
AOP代表的是一个横向的关系，如果说“对象”是一个空心的圆柱体，其中封装的是对象的属性和行为； 那么面向方面编程的方法，就仿佛一把利刃，将这些空心圆柱体剖开，以获得其内部的消息。而剖开的切面，也就是所谓的“方面”了。然后它又以巧夺天功的妙手
将这些剖开的切面复原，不留痕迹。
总的来说AOP 就是横向切割，解耦的一种设计模式。上篇博客，有一个简单的DEMO，那时我们一般使用AOP的方法。但是我们的解耦不仅仅是那样，这篇博客，我们进一步剖析一下AOP，看能不能让解耦再进一步。首先我们看一张图：

这是一张概念图，是对上篇博客的一种宏观描述，这种方式的最大的特点：服务（日志，事务）与代理类是一体的。这就是我们经常使用的方式，如果你不是太明白，那么我们来看看类图：

图中可以明显看到代理类：GreetingProxy 中包含了两个服务，一个是before，一个是After。这两个服务被写在了代理类中。那好问题来了，现在我要再增加一个服务：around，是不是还需要编写GreetingProxy这个代理类。也就是说，使用这种方式，服务和业务，我们只做到了单方面的解脱，业务的解脱，当然这已经是一个很大的进步了。现在我们需求提高了，我们想要让“服务”也解脱，怎么办？
于是我们有了这种图？

这样的话，是不是“服务”也自由了呢？你有和感想呢？接下来的几篇博客，我们将继续说AOP的优化。