AOP

AOP

作者：廖甲元

 

 

这是我准备的一篇讲义，不妥之处请大家指出，怕误人子弟:)

这是我准备的一篇讲义，不妥之处请大家指出，怕误人子弟:)

定义

     Aspect-oriented Programming (AOP)，面向方面编程。Xerox PARC 在1997提出的一个概念。和OO是相辅相成的。

    在我看来是GoF设计模式的延伸，设计模式的目标是将类进行解耦，AOP其实是更进一步或者说更大范围的解耦，将本来紧密相关的业务解耦；也可以说是更进一步的重构(refactoring)，业务重构--减轻业务变更和其他变更对系统的冲击，避免散弹式修改。

 

 

名词解释：

Xerox PARC: 施樂帕洛阿尔托研究中心（Xerox Palo Alto Research Center）是施乐公司最重要的研究机构，它坐落于美国加利福尼亚州的帕洛阿尔托，成立于1970年。

 

 

编织(Weaving) ：一个系统分解成多个Aspect后，最终还是要集成到一起，将各个Aspect组合到一起形成一个完整可用的系统就叫编织。

 

 

切入点(PointCut)：将一个Aspect插入到业务中的位置(时机)。分为before和after。

 

 

拦截器(Interceptor) ：又叫通知（Advice），切入点上执行的代码片段。一个特定事件触发时，一些行为能够被插入在调用者和被调用者之间，在一个方法调用者和实际的方法之间。这是AOP真正的关键。允许你去透明的应用一些事物，像日志和记录到一个存在的对象模型。

 

 

代理(Proxy)：请参考GoF设计模式。

 

 

附图:

目标、作用：

    目标是让开发人员将本来纠结复杂的任务分解开来。

 

 

关注点的分离（Separation of Concerns）：

    可以让不同的人专注于不同的事。一个开发团队中每个人都有自己的特长，有自己熟悉的领域，安全专家就带着他的团队编写事关系统安全的那个aspect好了，系统集成专家可以负责与系统整合的相关部分，业务专家则可以集中注意力于business domain，数据库专家则负责数据库相关部分。

 

 

主要应用于：

    日志记录，性能统计，安全控制，事务处理

 

 

好处：

提高性能：

    由各个方面行家负责自己擅长部分写出来的代码更简洁有效。

 

 

提高编码效率及质量

    良好的方面分隔可以大大减少重复代码，对业务的互操作提供更好的封装。可以减少团队成员之间的沟通消耗。

对于项目管理来说各个小组或团队成员大部分都可以并发进行，不用考虑那么任务之间的相关性，前后顺序，干特图好画了:)

 

 

重用

    对于公司来说有些Aspect在各个项目间是通用的，通过Aspect积累可以大大减少重复开发，成熟的、不断改进的Aspect的代码质量显然更高，也更好控制。

Jacboson说过类和类库的重用是低层次的重用，框架的重用高一个层，更有价值，业务的重用就高层次，这是另外一个话题--SOA，有机会再来讲解。

更易于扩展。

实现：

任何技术都不能只停留在理念，其早期实现是非常重要的，甚至关系到技术的存亡。

不仅仅是开发，其他学科也一样，象自然科学就有理论科学家和实验科学家，我们做事也一样，行动往往比空想有用的多。

Java：AspectJ、Spring、JBoss AOP...

.net：Aspect#、Spring.net...

 

 

Spring.net目前还只是实现了IoC，AOP部分尚在编写中，我的Blog上有个简单的例子。所以以Aspect#为例。

 

 

IoC：又叫依赖注射(DI)，具体请参考Martin Flower的一篇文章，链接附后。

 

 

Mixin：多继承，很多框架都实现了这个功能。并不是一个真正的AOP概念。

 

 

两种方式：

    编译时，将静态代码编译时就编织在一起，可理解性好，运行效率高。

运行时，通过配置在运行时将二进制指令编织在一起，更灵活，但增加复杂度，难理解，对运行效率有影响。

 

 

原始方法调用：

使用代理后：

不使用AOP实现日志Demo：

  简单方式
       Proxy模式
       Decorator模式

 

 

ASpect#日志Demo:

  略

Loom.net日志Demo

  略

资源

http://aosd.net 
   http://martinfowler.com/articles/injection.html
   http://zh.wikipedia.org/wiki/Xerox_PARC