AOP的解读

Aspect Oriented Programming（AOP）是近来较为热门的一个话题。AOP，国内大致译作“面向方面编程”。

“面向方面编程”,这样的名字并不是非常容易理解，且容易产生一些误导。笔者不止一次听到类似“OOP/OOD11即将落伍，AOP是新一代软件开发方式”这样的发言。显然，发言者并没有理解AOP的含义。
Aspect，没错，的确是“方面”的意思。不过，华语传统语义中的“方面”，大多数情况下指的是一件事情的不同维度、或者说不同角度上的特性，比如我们常说：“这件事情要从几个方面来看待”，往往意思是：需要从不同的角度来看待同一个事物。这里的“方面”，指的是事务的外在特性在不同观察角度下的体现。
而在AOP中，Aspect的含义，可能更多的理解为“切面”比较合适。所以笔者更倾向于“面向切面编程”的译法。
另外需要提及的是，AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。
而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。
上面的陈述可能过于理论化，举个简单的例子，对于“雇员”这样一个业务实体进行封装，自然是OOP/OOD的任务，我们可以为其建立一个“Employee”类，并将“雇员”相关的属性和行为封装其中。而用AOP设计思想对“雇员”进行封装将无从谈起。
同样，对于“权限检查”这一动作片断进行划分，则是AOP的目标领域。而通过OOD/OOP对一个动作进行封装，则有点不伦不类。

换而言之，OOD/OOP面向名词领域，AOP面向动词领域。
AOP和OOD/OOP并不冲突，我们完全可以在一个应用系统中同时应用OOD/OOP和AOP设计思想，通过OOD/OOP对系统中的业务对象进行建模，同时通过AOP对实体处理过程中的阶段进行隔离处理。即使不是OOD/OOP，而是在传统的POP（面向过程编程）中，AOP也能起到同样的作用。
将不同阶段领域加以分隔，这是否就算是AOP呢？
AOP还有另外一个重要特点：源码组成无关性。
倘若应用中通过某个具体的业务逻辑类实现了独立的权限检查，而请求调度方法通过预编码调用这个权限模块实现权限管理。那么这也不算是AOP。对于AOP组件而言，很重要的一点就是源码组成无关性，所谓源码组成无关性，体现在具体设计中就是AOP组件必须与应用代码无关，简单来讲，就是应用代码可以脱离AOP组件独立编译。
为了实现源码组成无关性，AOP往往通过预编译方式（如AspectJ）和运行期动态代理模式（如Spring AOP 和JBoss AOP）实现。
稍后章节中我们会就Spring Framework中的AOP实现机制进行更加深入的探讨。
下面先来看AOP中几个比较重要的概念：
1． 切面（Aspect）
切面，对象操作过程中的截面。这可能是AOP中最关键的一个术语。
我们首先来看一个应用开发中常见的切面：用户权限检查。大概只要是完整的应用，都少不了用户权限检查这个模块，不同身份的用户可以做什么，不可以做什么，均由这个模块加以判定。而这个模块调用的位置通常也比较固定：用户发起请求之后，执行业务逻辑之前。
针对权限检查这一模块进行分离，我们就得到了一个切面：
    切面意义何在？
    首先根据上例，假设我们实现了一个通用的权限检查模块，那么就可以在这层切面上进行统一的集中式权限管理。而业务逻辑组件则无需关心权限方面的问题。也就是说，通过切面，我们可以将系统中各个不同层次上的问题隔离开来，实现统一集约式处理。各切面只需集中于自己领域内的逻辑实现。
    这一方面使得开发逻辑更加清晰，专业化分工更加易于进行；另一方面，由于切面的隔离，降低了耦合性，我们就可以在不同的应用中将各个切面组合使用，从而使得代码可重用性大大增强。