• 2004-11-09

    成为开发者

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/487388.html

    这是一个很让人费解的标题,通常来说,程序员都是开发者。没错,对于我们的用户而言,我们是开发者,因此,对他们而言,我们拥有着无尽的魔力,可以创造出另外一个世界,而他们只能在我们圈出的土地上活动。不过,你是否想过这样的问题,在我们为别人指出一条明路的同时,自己也正在别人的鼓掌之中起舞。

    作为程序员,我们经常会做一些框架的用户。想必Java程序员们对于servlet并不陌生,很长一段时间内,我一直把它当作一个普通的API,需要的时候能找到有哪些方法足矣。近来在考虑系统结构的设计,实现了一个简单的生命周期框架,其中有一个生命周期事件监听的机制。所谓监听不过是Observer模式的一种实现,也就是发生特定事件之后,调用监听器通知它们发生了些什么。信手翻起手边的《Java与模式》,《Servlet技术中的模式》一章一下子吸引了我。虽然以前也曾经看过这章,但站在用户的角度,我只是想了解有些什么,而从未考虑过这些东西为什么这样设计,当我成为一个开发者,却发现了那是一个别有洞天的世界,Servlet技术中的一些概念一下子涌上心头,细细品味,原来它与心中构想的框架有着许多相通之处:各种Listener(ServletContextListener、ServletContextAttributeListener、HttpSessionListener、HttpSessionAttributeListener)提供的就是我要设计的监听机制,而Filter则与我构想中Interceptor机制异曲同工(JBoss的灵活就是由Interceptor达成的),Servlet在我的设计中对应了最核心的Service。我在思考框架设计的时候,灵活性是一个很重要的因素,与Servlet的印证,让我重新认识了这个熟悉的陌生人。好东西就在身边,只是自己有眼不识泰山罢了。对于框架而言,其设计者是这场游戏中最快乐的人,除了会得到开发过程中的乐趣之外,为别人制订规则的乐趣也是超乎想象的。

    框架设计者在得到属于自己的快乐同时,他们还要遵守语言设计者制订的规则。举个简单的例子,我们知道C++语言在C原有的值(value)、指针(pointer)基础之上又增加了一种引用(reference)。C语言已经用事实证明了自己的无所不能,值和指针已经足够完成所有的需求,而引用有不像类(class)、模板(template)之类的概念能够提供另一种抽象,那它的意义何在呢?我的答案是它不过是一种语法上的便利而已。在编译器实现的过程中,引用会以指针的形式表现出来,而在代码中展现出来的时候,它与普通的值丝毫不差。作为函数的客户端,代码编写时不再像以前指针那样需要额外的使用‘&’,这样代码看上去会干净许多,而效率上有不会有丝毫的损失。正是看中了这种代码上的干净,Java干脆去掉了指针,而丰富了引用的概念(可以置空、可以改写等等)。设计者体会到各种乐趣之后,给我们的只是一个设计的结果,不明就里的我们大多数情况下只能糊涂的遵循,而无法分享其中的乐趣。

    再来举一个例子,C++中有拷贝构造函数的概念,其实在Java中我们也会有用一个对象构造另一个对象的情况,但Java人却从不提及这个概念,这是为什么呢?原因在于C++中存在的pass by value。虽然在优秀的编程风格时,我们会尽量使用pass by reference,但pass by value依然不可避免,比如构造一个有理数类的乘法运算,我们只能以pass by value的方式将函数中构造出来用以存放乘积的临时变量传递到函数外部。pass by value就必须存在一个拷贝构造的过程,我们不可能直接将一块内存直接复制到另一边,因为如果类定义中存动态分配内存的部分(也就是指针),代码就会存在问题。关于这个问题,《Effective C++》有详细的讲解。为什么Java中不存在这个问题呢?因为Java中来回传递的都是引用,不涉及拷贝构造的过程。那C++中就不能像Java一样吗?抱歉,不能。前面说的pass by value不可避免的一个重要原因在于你不能把局部变量传出来,因为局部变量的内存会在函数执行完之后销毁,我们会因此体会dangling的现象。如果是动态分配的呢?在函数中new出一个对象传出去可不是一个很好的行为,那样我们至少要在文档中多费一些口舌来说明这块内存由谁释放。Java中为什么没有这样的问题,因为Java的内存是由GC负责。现在我们可以看出,GC决不止是内存管理这么简单,它的影响甚远得很。

    开发者和用户所能体会到的乐趣是不同。有许多人会认为软件开发了无生趣,很重要的一个原因在于他们只是规则的遵守者,而制订者对这场游戏则是乐此不疲。现在许多软件开发的书籍可以告诉你“HOW”,却很少说“WHY”。比如许多源码剖析的书,它会告诉你这段代码如何完成了功能,这种书看完之后,我们至多能够照猫画虎描出一个简单的例子,如果让我们自己来做,却往往不知道如何下手。因为我们只看到了结果,而没有其中的过程未能展现出来,而这个过程往往才是精华所在。

    似乎制订规则是一件很遥远的事情,其实作为自己软件的开发者,我们又何尝不是规则的制订者。尝试站在规则制订的角度理解一些问题,既可以学习规则制订的法则,也能提升自己对规则的认识,这样我们才能在这场游戏中更加游刃有余。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 呵呵 没什么赏识不赏识的 喜欢就是喜欢 不喜欢叫我说喜欢也难 呵呵 希望你再接再厉:)
    回复幻影肥猫说:
    率真的性格!
    2004-11-24 08:40:38
  • NND 写了三遍 .都翻了一遍 蛮合胃口的 呵呵

    在多写点吧 顺便问一句 你是大连的吧??
    回复幻影肥猫说:
    多谢你的赏识!
    我不是大连的。
    2004-11-22 21:17:20
  • 好久没有写把blog了,最近还好吧!
    回复hhee说:
    多谢你的关心!胡乱忙了一些东西,有一篇blog一直没有写完,看到你的关心,我要赶快了。^_^
    2004-11-21 22:09:06
  • 深有同感!可是水平有限呀,近来在研究tomcat一些实现原理,发现所学知识还甚有限啊。。。
    回复珂儿说:
    学习的结果不仅仅取决于想学什么,也取决于我们已经掌握了什么。
    2004-11-29 14:11:19
  • ^_^,不错。的确。很多时候,明白why,比明白how更重要。可悲的是,风气中,很多的人只满足于明白how。