Ivar Jacobson博士又来中国了。这一次，他仍旧在着力宣传用例与面向方面之间的关系。他的话听起来多少有些超前：当AOP对于我们都还是一个新鲜概念时，他带来的是AOSD，而且还要“with use cases”。我们绝大多数人对AspectJ都还不那么熟悉，大师带来的这些东西岂不是要让我们消化不良么。
不过，透过Jacobson博士反复数次的讲解，我倒是发现：或许脱离开那些实现细节之后，反倒能更清楚地看到AOP的内涵。也许我们太多地把注意力放在“AOP != interception”上面、放在“编译期织入 vs. 运行时织入”上面，反倒忽略了“AOP是什么”的问题。一个对象（或者说，一个对象继承体系）可以被认为是“一个业务模块”，那么一个aspect是什么？
一个aspect就是一个横切于所有业务模块的系统功能。譬如说，事务管理，不管任何业务模块（用户管理、报表、公文……）都要用到的功能。再譬如说，用户认证和授权，不同的业务模块都会用到它。可以把一个个业务模块（即对象继承体系）画成一条条经线，那么系统功能模块（aspect）就是一条条纬线。经线和纬线交织在一起，就构成了整个应用程序。从这一点来说，AOP用“织入”（weave in）这个词汇真是再贴切不过了。
不妨再把思路扩展一下。如果把坐标轴旋转90度，经线和纬线岂不是可以互换？事实正是如此：aspect本身也是一个对象体系，这里同样可以有继承、包容、聚合，同样可以有各种面向对象的设计模式。甚至当你设计的不是一个应用程序，而是框架时，你所做的事情就可能更多地集中在aspect上面。这时aspect变成了你眼中的主角，业务对象倒只是插入进来做测试和验证之用的配角。例如WebWork，在它基础上的拦截器可以做成一个相当庞大而复杂的体系，提供强大的功能，例如可配置的表单校验。
从上面举的例子还可以看到，aspect表达的“系统功能”也有层次之分：“事务管理”是很低层次、很技术性的；“用户权限”则是相当近业务的。也就是说，不仅业务模块（即对象）这里可以有分层抽象，aspect这里同样可以有分层抽象。比起Java对象，aspect的缺点在于缺乏强类型检查，优点在于更易于复用——实际这是同一件事的两个方面，脚本语言的AOP常常显得没有太大意义，原因也在这里。
所以这就是AOP：两个垂直正交的对象体系，一个描述业务模块，另一个描述系统功能，然后以某种方式把两者捏到一起去。了解这一点之后，对各种实现技术的理解也就更方便了。