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影响到大范围内的对象及系统的一些整体特性,因而更加需要工具的支持。