canonical

    Dijkstra认为程序运行时的指令序列是我们最终想要的东西，而这一序列是运行时根据源代码的描述在时间轴上展开的（串行结构）。因为人们更容易理解 静态关系而不是随时间演化的过程，所以我们应该尽量缩小静态程序(spread out in text space)和动态过程(spread out in time)的逻辑差距，因而我们需要使它们能够在一个固定的坐标系统(coordinate system)下形成对应。对于包括条件和分支语句的串行程序，我们只需要源代码的行号(line number)即可确定一个单一位置。在循环的情况下，我们只需要增加一个额外的循环计数器(loop counter)即可保证可理解性。而对于子例程(procedure)调用，我们可以认为整个调用堆栈(call stack)也构成坐标系统的一部分。goto导致一种非结构化的控制流，因而破坏了这种理解上所必需的独立坐标系统。例如，如果一个循环中充满了自由的 goto调转（可能跳出循环又跳回），我们就很难确定循环变量的值到底是怎么增加的，除非我们在脑海中把源代码运行一遍！
　　仿照Dijkstra的分析，Stoerzer指出AOP Advice虽然类似于procedure，但存在如下重要区别: 1. 与方法调用不同，advice执行位置在基础源代码中没有标识(obliviousness of application), advice有可能在任何位置插入并改变现场变量的值 2. pointcut可能依赖运行时变量值而无法静态计算得出(non-certainty of application)。
    第一点是由AOP技术的开放性造成的，但正如面向对象中的原则: open to extension but close to modification，我们需要遵循一些原则来避免破坏原有的结构。当然，AOP应用的场景可能确实只存在着某种弱可分性，advice需要深度依赖base code中的一些特性，可能应用类似模板(template)的技术会在一定程度上缓解encapsulation breaking. AOP的开放性造成的更严重的问题是pointcut在演化过程中的不确定性。只有在拥有全局知识的情况下才能确认pointcut的结果正是我们所期望的。特别是重构造成方法名改变之后，pointcut无法监测这种变化。当base code修改之后，我们可能没有意识到缺省影响到很多的aspect, 即完全理解base code变得非常困难。这种困境有一部分的原因是方法名同时作为调用标记和pointcut标记，责任过重造成的。参考一下css的选择符
   selector { property: value }

              \_declaration_/
   \___________ rule _________/
css可以通过选择符应用，也可以通过指定标签的class属性来应用，选择符所依靠的选择特征也可以不仅仅是标签名而包含属性名等。Java最近增加了与dotNet类似的meta attribute的支持，pointcut所依赖的元数据与方法名分离之后应该可以提高pointcut的稳定性。
　　关于第二点，实际上OOP中的Dynamic Dispatch在某种程度上也是需要动态计算决定的，但因为接口具有明确的概念含义（an overriding method should only expect less and provide more, by maintaining all invariants），我们可以在更高的层次上理解代码，而不需要具体到特定的实现。AOP目前可能是缺乏一些指导性的设计原则。
　　相对OOP而言，AOP影响到大范围内的对象及系统的一些整体特性，因而更加需要工具的支持。