1。随处可见猜想。
在未来的软件开发过程中，AOP将以一种基础编程能力的形式出现，与OOP共同发展，成为主流开发环境的一个组成部分。而目前为止，AOP只是作为一种开发工具、或运行时代码而存在。到了那个时候，可能没有哪个产品声称：“我使用了AOP”，因为没有哪个产品没有使用AOP，就像现在没有哪个产品没有使用OOP一样。就算你的源代码中没有应用到编程语言的AOP能力，你也可能调用了某个应用了AOP的基础库。事实上，AOP之父Kiczales认为AOP可能首先在操作系统上有一定规模的应用。

2。语言级猜想。
AOP的真正实现是在一个特定的语言基础上的。比如数年之后，人类开始普遍使用K语言（K是J的后一个字母），K语言在语言本身上就可以编织和横切。此时AOP才得到真正的成熟，因为程序员在编写代码时可能根本不知道自己用到的是曾经的OO还是现在的AO，只有了解K语言虚拟机构造和背后实现的人才知道。但是，可能由于人固有的思维方式的问题吧，AOP仍然不会比OOP要使用的更多，甚至有可能仍然是Kiczales所提到的15% Solution！但是，从语言的角度去实现AOP也许会给人类的编程观念带来巨大的变化，这种变化就像OO所带来的一样。

3。存在AOD/AOA猜想。
OOP对人类的影响远不如它的两个弟弟OOA/OOD，后两者已经为整个软件开发行业带来了一次意义深远的革命，它至少使得全世界开发团队的人数扩大了10倍，开发工具和平台的复杂程度增加了10倍，完成客户某些简单要求的成本降低了90%，唯一的遗憾的是，软件开发的效率几乎没有数量级上的变化（依据《没有银弹》）。既然存在AOP，我们猜想也会存在AOD/AOA，比如会存在面向方面的重构手段，面向方面的设计模式，面向方面的最佳实践，面向方面的过程管理，以及在UML的未来版本中看到为面向方向而专门做的改进，甚至添加一个新的UML图类型。当这些东西都产生的时候，AOP才真正发展到了鼎盛时期。

4。可执行用例猜想。
AOP是一个广泛适用的充满想象空间的新技术，但是目前人们对AOP的研究方向过于狭窄，大部分声称正在研究AOP的开源项目其实是把AOP当成一个辅助工具来使用，这些项目中又有相当一部分是在做企业开发环境下的容器，他们并没有针对AOP本身进行开发。事实上，依照Jacbson的说法，AOP将直接导致软件的开发分为两种形式——对模块的开发和对用例的开发，现在的用例仅仅是图纸，必须要转变为OO代码才能执行，但是一旦有了AOP，AOP可以直接依据用例的定义，将多个不同的模块（可能来自不同的开发单位）连接起来，形成方面，而方面本身是可以执行的（语言级猜想），所以用例也就不再是图纸而是可以执行的了。这对于以UML为核心的现代软件过程来说，是个极好的信号。

5。标准化猜想。
OO的成功经验告诉我们，要想取得最后的胜利，就要一致对外，统一了内部的概念，剩下的争论就只有实现问题了。我个人认为，多数OOP语言在概念上都是一致的，这种概念被语言学称之为语义，多数OOP的语义来自Smalltalk和C++这些早期尝试者，少数来自Java这种在技术的成熟期涌现出的商业产品。AOP目前还面临着这个问题。业界对AOP的标准化过程有两个猜想，一是由AspectJ领头，各大AOP实现都以AspectJ的语义作为研究问题的基本用语，设计和实现沿用现在的思路；另一个猜想是由权威组织，（开源、商业、或全球研究组织），如Eclipse/IBM/OOPSLA等等拿出一个统一的AOP语义内核，所有AOP项目都以该内核为基础开发。Java虚拟机是前一种思路的成功案例，后者则以XML为代表。

6。全静态编织猜想。
下面讨论一个实际的技术问题。时下多数AOP项目采用的编织技术无外乎两种：静态编织和动态编织。前者是指在编译前（预编译期）、编译期、和编译后编织，后者是指在运行期编织。Kiczales认为虽然没有明显的技术缺陷，但动态编织可能会面临一些发展远景的问题，他称之为“软件的演化问题”。不知道我对大师观点的理解是不是准确，我认为由于被编织的代码是在变化（发展）中的，我们总是希望这种变化对编织本身的影响最小，这时静态编织面临的问题最多就是重新编译，而动态编织可能不会那么简单。此外，全静态编织会导致另一个优点——这听起来有点奇怪——就是能力较弱，因为全静态编织继承了OO语言本身的约束，比如Java的约束和.NET之CLR的约束等等，这对于更规范的使用开发利器是大有好处的。“应该对人类准备大规模应用的每一种新工具小心钳制。”

7。AOP的诞生之迷猜想。
Kiczales先生在从事AOP的研究和开发之前也曾接触过其它对OOP的改良研究，其中包括反射和元对象技术。事实上，心平气和的说，后两者的变通能力和灵活程度都在前者之上，但是正因为如此，语言学家们认为，这些技术并不能有效的改善OOP的弊端，甚至还有可能引狼入室，带来新的“狼人问题”。后来，当Kiczales发现AOP时，他明白这才是人们真正需要的，他认为他们抓住了问题的咽喉。时至今日，AOP的实现技术已经千姿百态，百家争鸣了，但是，AOP创立之初的种种想法也在这种百花争艳中渐渐被人们遗忘，现在利用反射、元对象技术以及种种双刃剑式的技术来实现AOP的想法已经像争抢参院席位一样争夺市场的认可，这是事物的发展还是理想的倒退？AOP何时才能回归它的本原？上天为它安排的命运究竟如何，我们拭目以待。

最近，我和我的几个朋友正在组织一批开源斗士们合作编写AOP.NET，这是一个开源软件，在博客园上可以看到部分有关该项目的消息。但是由于种种原因，我们对一些基本的问题还没有达成共识，本文来自我对AOP的一贯看法，也是我对社团里很多问题的一个集中性回答吧。

开源泡泡
（转载本文需注明出处：Brian Sun @ 爬树的泡泡[http://www.blogjava.net/briansun]）