• 2003-12-14

    AOP初印象

    Tag:向上走

    这两天看一下《DDJ软件开发》上关于AOP的两篇文章,算是对AOP有了个最初的印象。

    在我看来,AOP所提倡的实际上是个哲学问题,“从不同的角度看问题”。
    所以,如果把AOP中的"方面(aspect)”换成我们熟悉的“角度”,我觉得这个概念就可以更好的理解了。

    我是一个Java程序员,和我同住的一个兄弟是C程序员。
    某天,他突然问我,对网络的了解多少,我说很少,他很惊讶,你们项目不也是基于网络的程序吗?怎么连对网络了解得都不多。

    其实,这就是一个关注点的不同。
    如果用C写程序,那就不得不面对直接编写网络程序的问题,解决诸如Socket连接、并发等等问题,为什么,因为如果自己不做,没人会帮忙。
    如果用Java写程序,恰好又是一个基于Http的应用,那就省去对网络程序的关注,因为这些问题已经有人完成了这些工作,他们就是那些开发WebServer(比如Tomcat)和AppServer(比如JBoss)的那群人,在此基础上开发应用的人,大可不必理会究竟请求是如何进来、并发如何处理,只要放心大胆的去做自己的应用就好了。

    关注点不同,对于同样的问题就会产生不同的理解。如果因此争论不休,才真正是“风马牛不相及”,网上许多关于语言或工具的争论往往都是这样开始的。

    回到AOP上,其实一个aspect就是我们看问题的一个角度,我们所关注的一个问题,一个关注点。

    再来说说《DDJ软件开发》上的两篇文章,《AOP之父Gregor Kiczales访谈:15%解决方案》放在《AOP入门》之前,于是我按部就班的先看了《访谈》,结果连一半都没看下去,几乎看不懂。只好先看《AOP入门》,对程序员来说,是有代码的东西最实际,看过《AOP入门》回过头来看《访谈》,许多疑问迎刃而解。所以,如果哪位和我一样对AOP感到陌生的兄弟姐妹想要读这两篇文章,我推荐先看《AOP入门》。

    就上面所举的例子再多说两句,例子无非是用来说明我的观点。对于我对网络知之甚少的情况,我自己是深感愧疚的。鉴于大多数时间把精力都集中在应用上,以致于我现在只能以“架构”、“模式”等比较“炫”的词来敷衍别人。在我看来,只有有了良好的基础,写起代码来才能虎虎生风,否则,无异于盲人摸象,很难看清事务的本质。

  • 经过了一段的实践,忽然发现自己最应该掌握的是一些基本的东西,比如数据结构,比如编译原理,比如操作系统,这种感觉随着自己实践经验的增多而愈加强烈。

    学习编译原理和操作系统的意义并不在一定要实现出一个编译器或是操作系统,关键在于学习其中的许多思想,开阔自己的思路。很可惜,念书的时候,我没能找到一种很好的学习方式,以致于虽然不断的告诫自己这两门课的重要性,最终仍未能让其刻骨铭心。

    以我现在的眼界来看,学习这两门课最好的方式是结合源码,操作系统当之无愧就是Linux了,编译器我觉得Gcc不错。oldlinux.org上的赵博士为0.11版的Linux做了份注释,写了本书,我只看了开头不多的一点,感觉还是很不错的。有了问题还可以到网站上去问问题,赵博士挺热心。

    相对来说,Gcc的资料趋近于0。最近我认识的一个高手在研究Gcc,我有幸分享了他的一些成果,受益匪浅。等我小有心得的时候,也把自己的学习成果贡献出来,和别人一起分享。

    说了半天,都快忘了我今天blog的题目了,我买了《算法导论》,这可是本经典的作品。

    Pascal之父Wirth博士的经典论断就是“程序=数据结构+算法”。

    我不知道别的大学是怎样的,我的大学课程中,数据结构进行了专门的讲解,但对算法几乎没有涉及,加上大学中误把二者等同起来,结果造成了现在基础不是很扎实的结果。

    书买回来了,最大的疑问是我能从中获得多少东西。我并不怀疑这本书的经典程度,我怀疑的是自己的学习态度。
    1 书的厚度近1200页
    2 书是英文的
    买书的时候,同去的兄弟就对此提出了置疑,我大言不惭的说,我一定会好好看看,认真的去实践,心里却在打着鼓。

    写下这篇Blog的目的,一是纪念一下为《算法导论》而阵亡的诸多Money们,二是告诫自己,开始学习吧!

  • 早早就申请了这个Blog,却迟迟没有写过一篇,对于多少还算比较喜欢码字的我来说,有点说不过去。于是决定多多少少写点东西,也算对得起自己了。

    既然是个程序员的Blog,话题当然离不了程序。近来比较忙,一个已经做了一年的项目又有了新需求,加上我们项目组的人那么积极上进,于是乎,大家决定为系统设计一个新的架构,版本号也顺理成章的由1.X变成了2.0。

    部门里人事变动,负责人升级了,我们项目中本来负责系统架构的兄弟成了负责的,于是他的活转到我的手里,我成了这个新架构的“架子工”。

    近两个月在看Uncle Bob的《敏捷软件开发》,终于对OO有点开窍了。最近一期的《程序员》gigix那篇关于IoC的文章看得我心潮澎湃。IoC实际上和Uncle Bob所讲的DIP基本上是一回事,有了DIP的一点底子,看IoC就有感觉多了。手头上有gigix的Groller,文章加代码看得我越发有感觉,于是想在新架构中对这些“感觉”进行尝试。

    Groller中的IoC基本上是借鉴了Spring中Bean操作来完成的,所以我也投了一些精力在Spring上,随着对Spring的了解,我的思维开始发散。既然能够把一些组件(bean)配在xml文件中,由Spring来替我们完成组合,那我把整个系统都看作一个组件集如何呢?

    gigix在Groller里进行了一些尝试,他把一些service按照组件进行配置,只不过他的service组合还是比较简单的。我想可以再进一步,把整个系统都以这种方式组合起来,即大的service由小的service组成,这样一点一点把整个系统拼接出来,所有的配置都由配置文件完成。

    和gigix就这个问题讨论了一下,他觉得小service应该是大的service的一个aspect,可惜我不懂AOP的概念,所以,我只能以“小service是大service的一个组成部分”来理解。

    渐渐的,我开始觉得AOP是个好东西了。有人说面向过程如果是一条线,那么面向对象就是一个面,到了AOP就是一个体了。既然可以由一维逐渐演化为多维,看来还可以再进一步,让它变成一个多维的。

    类比一下,我觉得操作系统的文件系统也可以设计成一个多维的。比如我们组织自己手头的资料,可能C中有电子书、有网页,Java中也有电子书、有网页。如果我们换个角度来看:电子书里有C的、也有Java的,网页中同样有C有Java。由此看来,现在的文件系统也可以再进步一下,不必维持现在这种单一的树形结构了。

    呵呵,已经偏离起始的内容好远了。这就是思维混乱的结果,随性而行,差之毫厘,谬以千里。