posts - 80,comments - 749,trackbacks - 2

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])

posted on 2005-08-31 13:53 Brian Sun 阅读(3995) 评论(3)  编辑  收藏 所属分类: 软件

FeedBack:
# re: 关于AOP的七个猜想
2005-09-05 12:56 | steeven
偶比较期待VM级别的支持。通过一个标记就搞定  回复  更多评论
  
# re: 关于AOP的七个猜想
2005-09-05 15:14 | Brian Sun
你看:
http://www.blogjava.net/briansun/archive/2005/09/02/11844.html

这个吧,你的愿望马上就要实现了,哈哈。
  回复  更多评论
  
# 读《关于AOP的七个猜想》之打岔[TrackBack]
2005-10-11 00:09 | 敲门
[引用提示]敲门引用了该文章, 地址: http://blog.donews.com/komantian/archive/2005/10/11/583738.aspx  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航: