AOP的学习序曲

在6年前，曾经通过MSDN一篇介绍如何通过修改VTable的技巧，使COM组件实现Aspect oriented programming的文章。那是我第一次接触AOP的概念。通过阅读那篇文章，只是给了我一个很强的技巧性的印象。至于通过拦截方式，实现的这种服务分层或行为扩展的技术，能给我们这些普通的程序员带来些什么，还模模糊糊。只是隐隐约约的觉得，它很适合构造系统级的东西，也只是一种可能只在特定领域内使用的高超技术。

 

至从我两年半前转入Java领域以来，就又开始不断的听到新鲜的AOP， 成了一种程序员世界的时尚。因为JBoss 2003年大胆的在其4.0版上使用AOP架构设计技术，以及2004年Spring的热潮涌起，我已经深刻的感觉到AOP已经是一项非常非常重要的成熟的技术了，是到了该掌握和学习的时候了。

 

通过这半年来断续的对Spring中的AOP架构和运用方法的学习，对AOP的常见的应用场景如Security、Cache、Transaction等服务切面实现应该说是有了比较“正确”的概念和认识。但AOP还能怎么用？应该怎么用？难道它适合的场景就是类似于上面所提到的系统服务实现吗？

 

时刻带着这样的疑问，在一个Google搜索的偶得中，我找到了一篇Use Case创始人Ivar Jacobson（UML三巨头之一）的“Use Cases and Aspects Working Seamlessly Together”幻灯。（在我读过该幻灯几个月后，程序员杂志才刊登了同样内容的一篇Jacobson的译文）。在该幻灯中，Jacobson强调了自己的历史上天才的感悟和哲学思考能力，在20几年前所参与的一个电信项目中就使用了类似今天AOP概念的思想进行了系统结构设计（这里先深深的对大师表达一下敬仰之情）。

 

该幻灯中论述了这样几种论题。

         组件方法不足够以解决软件问题

以组件的方法来看待一个系统时，你看到的是一个静态的结构。我们通过该方法来理解系统的设计、实现、分布、测试、配置等诸多方面。同时组件还提供了最为重要的复用能力。但在组件或更为底层的对象中，还是存在着不那么完美的地方。即组件/对象与需求往往不是最直观的直接的映射，而是要经过抽象、分析、变换、设计后得到的。一个需求的实现，往往会跨越多个组件，这称之为散落， 而一个组件本身往往包含着多个需求的实现部分，这称之为缠结。因此我们需要一个新的方法来补偿/增强原有的面向对象方法。

 

    用例中的切面问题

         用例的扩张