|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
时间:2004-08-04
AOP, AOP, AOP, 打开偶的rss reader, 每天总有几个嗡嗡作响的蚊子在念叨着AOP, 国外炒做了一年多了, 按照2年的时间差, 国内估计也要开始嗡嗡作响了. 好吧, 在它开始烦人之前, 让偶来念念它.
先来做一算命先生, 算算它的life cycle: 1. 一些人象探路骑兵一样开始探索AOP的地图 ( 如果你玩过即时战略游戏的话, 应该知道偶在说什么) 2. 幸存下来的骑兵开始嗡嗡作响, 写一些文章拉, 扔出一些看上去很拉风, 很臭屁的代码呀. 3. 事情刚刚开始的时候, 看看上去总是不错的, 因为大家还只会用AOP做些糊弄人的简单东东. 4. 一些行动迟缓的象兵开始跟进, 有样学样了, AOP In Action之类的书估计也会出来了, 当然, 国内那些翻译家又有事情做了. 5. 随着时间的发展, 随着应用的复杂, AOP开始展现出它的缺点来了. 6. 有人开始写 "Bitter, Faster AOP", "J2EE without AOP"的书了, 翻译家又开始高兴了. 7. open source SummerFramework出来了 8. 新的XOP概念冒出来了, 一个新的循环开始了...... 下集预告: Log, Cache, AOP的常用谎言? (嗡嗡作响的AOP系列之二) 声明:JavaEye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
|
|
| 返回顶楼 | |
|
时间:2004-08-05
呵呵,期待ing
Log, Cache可是AOP的御用例子啊! |
|
| 返回顶楼 | |
|
时间:2004-08-05
Readonly 上次说的“一个设计良好的OO架构, 完全可以让这只苍蝇滚蛋”,我比较赞同。目前我们必须要采用 AOP 方式开发的场合几乎没有。我尊敬的是能够基于简单的技术(例如:JavaScript)化腐朽为神奇的一类人,而不是有了新技术忙不迭地跑去学,然后写出一些似是而非的粗浅入门文章浪得虚名的家伙。不客气地说,这些人起到了误导初学者的作用。初学者总是喜欢迷恋一些华而不实的东西而忘记了对基础知识的巩固。国内有相当一批的这类人,迅速窜红成名对于他们是比什么都要重要的大事。
AOP In Action 没有出,AspectJ In Action 已经出了很久了。 我不是反对 AOP,而是反对对 AOP 的盲目崇拜。只有剥去神圣的外衣,我们才有可能更深入地探讨 AOP。 |
|
| 返回顶楼 | |
|
时间:2004-08-05
第一,AOP和EJB最大的区别在于它——至少在目前——没有多大的商业价值,所以它从来没有、将来也不会变成buzzyword。第二,国内的很多人早就在研究AOP,研究它适用和不适用的场景,即使我本人,在真实项目里使用AOP也已经超过一年了。第三,我很反感你(readonly)说话的语气。在我看来这种语气有点像我一个朋友的小女儿说的话:“吸不出的螺蛳都是臭的,吃不着的葡萄都是酸的。”
|
|
| 返回顶楼 | |
|
时间:2004-08-05
补充一句,早在去年这个时候,我和potian就讨论过:Log压根不是适用AOP的场景。我在JavaEye上次组织的交流上关于AOP的演讲,也曾经提到过这个观点。至于Cache,potian现在做了一个基于AOP的Cache产品,在他的项目里用得很舒服,也许你可以先去看看他的产品怎么做的。
批评buzzyword,没问题,麻烦先充分了解这个buzzyword——至少该比你想批评的那些鼓吹者要更充分。 |
|
| 返回顶楼 | |
|
时间:2004-08-05
对于新技术,我的态度是注意但不盲目跟进
没有AOP,你依然可以写出一样的程序。就像没有OO以前,依然后很好的程序被写出里 AOP最大的问题应该是上下文信息不足。比如常用的log例子,用了AOP,你能做到什么呢?记录一下那个类的那个方法在什么时间被调用了,仅此而已 |
|
| 返回顶楼 | |
|
时间:2004-08-05
aop能够搞定的应该是本来就是松耦合的东西。如果耦合的紧密一些,用AOP去搞,会搞死。
那个log和cache也一样,aop在这里的适用范围其实很小,假设这个log/cache和业务逻辑强烈相关(一般我看也是,我要log的那些东西大部分是重要的业务处理过程的中间状态和最终结果),用aop去搞定它,首先看起来就是同样一个东西需要以不同的面目出现在了多个地方(因为需要做到对被log的对象透明,所以关于要log什么东西的定义必须出现在另一个地方,程序或者配置文件中),感觉上就不爽。cache也一样,实际上所有的cache后面都有自己的隐义在,一个是cache本身的实现,这个现在多了去了,opensource的都遍地跑,另一个更加重要的是cache的东西的选择,这个选择是要考虑命中率的,一考虑这个,就又和某些东西相关了。我的感觉是,现在大家一谈cache,都不用谈命中率的,好像只要有个cache的实现,把东西扔给它就万事大吉了。 我觉得aop的最大用处是在对遗留的java程序的改造上。 |
|
| 返回顶楼 | |
|
时间:2004-08-05
gigix 写道 第三,我很反感你(readonly)说话的语气。在我看来这种语气有点像我一个朋友的小女儿说的话:“吸不出的螺蛳都是臭的,吃不着的葡萄都是酸的。”
你听他说下去啊,他的招式还没使出来,你的招式出的早了点吧。学学太极吧,后发制人置人于死命。即使你现在已经革命了,也要允许其他不革命或者等待观望的人分批参加革命吧,否则不是成了拒绝阿 Q 的那个“革命者”假洋鬼子了吗? 还是让这个话题自然地展开吧。刺激性的语言大家还是节省点,呵呵。 |
|
| 返回顶楼 | |
|
时间:2004-08-05
要评价,就必须首先理解它。如果只是因为它现在很拉风,感觉这不是治学之道。好不好倒是其次,关键是它能发挥多大用处才是我关心的。
我看过Adrian Colyer 用aspectj来实现cache的例子,自我感觉很棒,简单、直接并清晰,做到了java本身做不了的功能。而且 Rickard Oberg已经在他的产品中开始应用他的AOP框架。 |
|
| 返回顶楼 | |
|
时间:2004-08-05
gigix你也要注意语气了。
对于aop我的态度是中立的观望,有前途,但是未必有钱去图,更谈不上有钱可以图,所以还不能说有钱图。 而我认为现在问题的关键不是如何实现AOP,而是如何使用AOP的思路去分析问题,从而使AOP不仅仅只存在于代码中。相比较而言,现在的AOP工具仅仅只是一种工具,它们并没有提供给我们一个使用这个工具的说明书。 |
|
| 返回顶楼 | |












