入门不简单(《Beginning C# Objects中文版》书评)

由于工作性质的关系,我常常需要为公司面试程序员。通常,我会首先要求应聘者做两件事:第一,口头说明虚方法、抽象方法、接口之间的异同和使用场景;第二,脱离IDE,手写一个简单的WinForm程序(例如包括布局整齐的两个文本框和三个按钮、点击按钮弹出消息框显示文本框内容),然后在命令行编译运行。第一题是考面向对象中的继承和多态概念,第二题则是考C# GUI类和关于委托等C#独有特性的基础知识,以及编译、调试技巧。很遗憾,有一大半的应聘者会在这两个简单考题面前败下阵来。尤其是第二个考题,甚至难倒了一些写代码有年头的程序员。为什么?因为这些程序员不具备基本的面向对象知识,更加不理解C#的面向对象实现手法。


这不能完全归咎于中国计算机教育。实际上,在美国或其他发达国家,真正懂得面向对象开发的程序员也并非随处可见。这也是Beginning C# Objects(及其Java原版本Beginning Java Objects)一书成为畅销书、并在Amazon上获得读者极高评价的原因。作者写道:“我们常常与一些软件开发者会面——在工作场所、在客户办公室、在专业会议上,或在大学校园里——这些开发者都尝试去掌握一门类似C#的OO编程语言,他们参加C#培训、阅读关于C#的书,或是安装和使用像Visual Studio .NET这样的C#集成开发环境(IDE)。然而,这是舍本逐末的做法:他们缺乏对什么是对象的基础认识,更为严重的是,缺乏利用对象从头开始构建软件应用程序的知识。”


翻开市面上任何一本你能找到的C#入门书,看看第一章讲什么,第一个范例是怎么实现的。闭上眼睛你都能告诉我,第一章多半是讲怎么安装VS.NET,第一个例子多半是拖一个按钮控件到窗体,双击后输入一段调用消息框的代码。我们的技术作者们,就是这样把读者引入歧途的。IDE(集成开发环境)能极大地提升生产力,但开发应用程序所需的高度专业的知识和技能,却非IDE所能代替。的确,任何一个菜鸟也许都能利用可视化组件拼凑出“看起来还不错”的应用程序,但这样的程序却将带来高昂的扩展和维护成本。


面向对象编程,绝非一些可视化组件那么简单,它涉及人类思维(抽象)模式、建模符号体系、面向对象方法学等诸多方面,对开发者有较高的要求。功夫过关的开发者,不止是技术高手,同时也一定会是有深度的思想者。把需求从自然语言翻译为对象模型,再把对象模型翻译为特定语言代码,殊非易事。最基础的,到底什么是对象?如果你曾经好好思考过这个问题,就会得到很多启发。例如,现实世界中的一张纸,如何抽象为计算世界中的对象?这个对象将具有那些特性(属性和行为),例如尺寸、颜色、质地、折叠、裁减,卷筒……?综合来看,面向对象的要素是什么?把事物抽象为对象的过程,是做思维体操的过程,也是极富挑战性和乐趣的过程。如果你还还不了解对象和面向对象的概念,或想与作者一起就该话题做更深入的思考,那本书第一部分就是最好的入门手册。


我认识一些优秀的程序员朋友,他们在大学时念的专业是建筑。这些朋友对应用程序架构和/或开发流程,有近乎严苛的要求,因为他们深刻地理解,蓝图、材料、工序……对于建造房屋是多么的重要。对象模型的静态方面(域类、数据结构等)在应用程序中开发相当于建材单元,而动态方面(行为、方法等)则是关于建材之间如何组合的指导书,它们合起来,构成一个应用程序的“蓝图”。越是复杂、大型的应用程序,对蓝图的要求就越高;即便是简单的应用,有蓝图也比较有利于维护、升级和扩展。给你一份需求说明书,你将如何分析它、并且组织出正确的对象模型(蓝图)?如果你对此信心不足,建议好好阅读本书第二部分。


第三部分涉及的范例,在有经验的开发者眼中看来,似乎过于简单。其实不然。整个开发过程当中,没有使用IDE拖放过任何一个控件,或在IDE中编译调试。这样做的目的有二:一、让读者可以掌握.NET Framework和C#本身的特性,而不会被IDE的花哨界面所迷惑、急于求成;二、帮助读者学会用正确的手法和模式(如公认的MVC模式)开发程序。例如委托(delegation),这是.NET Framework中一种特别的语言元素,也不易理解。如果你只懂得往窗体放一个按钮,双击该按钮,输入一行代码,那么你永远不会明白,这个过程体现了利用委托实现事件处理的巧妙手法。但是,如果让你脱离IDE编写事件处理方法,你就很快能明白这个道理,而且也知道怎么用于实践。IDE能提升生产力,不过它却不能凭空创造生产力,本源的生产力还是来自开发者的知识与技能。


面向对象编程已经流行多年,然而还是有无数的入门者在入门阶段就走错路子,抱着错误的观念、用错误的方式开发着意大利面般一团乱麻的程序。入门不简单,对于初学者如此,对于有经验的开发者,更该回头检讨自己在面向对象编程领域的经验是否根本就是错误或细枝末节的经验。本书作者开发和培训经验丰富(一位是NASA开发工程师,一位是大学教师和对象技术专家),理解面向对象程序员可能进入的误区和面对的挑战,他们知识与经验的总结,形成了这么一本用心良苦、循循善诱、深入浅出的C#面向对象开发指南。每一位C#开发者,无论有经验还是没经验,都该读读这本书。入门不简单,你真的入对门了吗?


(本书将由电子工业出版社于2006年5月出版)

噩耗

我在《师友杂忆(一)》一文提到的马彪先生,在今晨,被人发现,吊死在小凤凰山顶的一棵松树上。死亡时间,据说是昨日中午。自杀还是他杀,目前尚不敢断言。如果是他杀,先生死得冤枉;如果是自杀,作为一个穆斯林,先生要被逼到何种程度才会选择这条路?无论如何,一个人就此消失了;我和我的同学们永远失去了老师,他的同事们永远失去了同事,他念高中一年级的女儿永远失去了父亲。


老同学让我写一篇悼念文章,我不知道从何下笔。我从心底里把马彪先生当作最可敬佩的师长,同时也不谦虚地把自己当作是他最好的学生;仔细想一下,其实自己完全不了解他。我们像是两只小心翼翼互相取暖的刺猬,保持着不足以刺痛对方的礼貌的距离。现在,这距离变成了生与死的距离。


马彪先生,此生缘尽,您走好。死者已矣,生者保重;我们这些侥幸能看到今天太阳的,一定要好好活着,看到明天的、更灿烂的阳光。

旧影


孩子站稳
抓紧父亲
车经过时
他会离开
剩你一人
斑马线旁
孤独等车

观影语录

《小喇嘛看世界杯》,结尾时主持的开示:


能用皮毛铺地,免得走路时脚底受伤吗?不能。那怎么办?穿上皮鞋走。在地上铺皮毛,和穿皮鞋效果没有区别。同样,敌人充满空间,永远无法全部打败。只有战胜自己心里的仇恨,才是解决敌对的正确方法,让你免于受伤。

承认多元化,保持宽容

1976年2月3日,比尔·盖茨给电脑爱好者们写了一封公开信,抱怨未经授权使用BASIC的情形,已经到了无可忍受的地步。这封公开信被看作是导致商业软件真正成为一个行业的始推力。在从1976年到2006年的三十年间,微软和另外一些公司受益于软件商业化、成功做大;也有一些持不同意见的人,不断推动自由软件/开源软件的发展。到今天,自由/开源软件与商业软件已现鼎立之势,而两方的拥趸之间的争论、指责甚至谩骂,也从来没有停止过。


争论并非坏事,指责就有些涉嫌用自己的价值观或道德观去判断他人,至于谩骂这种等而下之的行为,不说也罢。价值观和道德观,在不同文化里面,甚至在不同人观念里面,都有差异;所谓社会道德,或社会公认的价值观,或形而上的法律,不过是大家经过一番争斗、求同存异的产物。能够存异,前提是要求同;设若大家都不肯求同,最终只好用最不道德的方式解决问题:也就是用暴力压服对方。


商业软件,无论是开发模式或是经营模式,经过三十年的雕琢,已臻于成熟(或者说僵化,如果你喜欢);自由/开源软件能有今天的成就,也自有其存在和发展的价值在。有一点必须承认,无论是商业软件还是自由/开源软件,都给计算世界带来了自己的贡献。一棒子打下去,打死谁都是冤枉的。


我相信争论、指责甚至谩骂,仍将继续;商业与自由/开源之争,一时半会儿也定不了胜负。我们应当鼓励争论,更应当鼓励双方在自己的阵营里面、按照各方自己的模式,做出更多更好的软件产品。只要有用户愿意花钱购买软件,商业软件仍有其生命力在;只要有开发者愿意开放源代码(不管是否从其他方面获利),开源软件仍有其生命力在。惟承认世界是多元化的,而且愿意宽容“非己”的存在,才有求同之可能;惟求同,才有存异之可能;惟存异,才有进步之可能。


要提防的只有一种人,他们喜欢用自己的规则玩别人的游戏。以“我认为商业软件是恶的”这种借口去盗用商业软件,就是一个例子。另一个的例子,国内某些Linux发行版厂商,拒绝遵守GPL协议,迟迟不开放自己发行版的源代码;在各种压力下终于开放源代码后,又抱怨GPL协议妨碍了软件产业。还有更离谱的,拿开源软件代码改上一改,就号称“拥有知识产权”,当商业软件卖。这些例子并非杜撰,有心人一看便知主角是谁。


还是那句话,世界是多元的,每个人的“异”成就了大家的“同”。承认多元化,保持宽容,按规矩玩游戏,世界会更加“春田花花”。


附:比尔盖茨当年的公开信


比尔盖茨公开信,点击看大图

电梯动物

电梯里,一对牵狗的夫妇和一个单身男子。


大家沉默到第5层时,单身男子问:您这什么狗啊?


遛狗归来的夫妇二人,似乎不适应被问,齐声答曰:啊……然后反问:你是问狗的性别还是种类?


单身男子也顿了一下:种类。


遛狗男子说了一种狗的名字,单身男子在14层下了。


女的对男的说:我以为他问公母呢,这狗跟他一样,是公的。

别后

由羊坊店东路
仓皇逃离
正宗河南烩面
高音喇叭唱豫剧
余音未绝时
西客站大钟敲六下


遵嘱裹好自己
遵嘱保重
北京正三月
南风比北风还冷


再绕一个街角
地铁站如约守候
遵嘱保重
早些回家