近10年来最重要的软件开发书籍《设计模式》

10年来最重要的软件开发书籍《设计模式》<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

蒋涛

前言

两年前曾经在中国计算机报写过几篇书评,那时候感觉软件开发方面的书籍虽然不少,可是精品屈指可数,仅有的几本老牌经典名著还版本陈旧,如Charles Petzld的《Windows开发指南》、 Jeffrey Richter的《Windows高级开发指南》、David Kruglinski的《VC 技术内幕》等。这两年可能是互联网给软件业注入了新活力,再加上软件从业人员迅速增加,各家出版社争相出版计算机图书,使得情况大为改观。虽然书目让人眼花缭乱、书籍价格也越来越高,可是整体质量良莠不齐。很多国内编著的技术书籍号称“高级编程”,实际上只相当于入门手册,有的甚至将帮助文件翻译出来也能出书,而且一版又一版,乐此不疲,这真是出版界的悲哀!

我是很喜欢买书的人,技术领域里几乎没有人不需要读书。有时候在书店看见别人左挑右选,最终拿着几本质量低下的图书却如获至宝。真想拉住他,告诉他孰优孰劣。不过我们中国人好像不太习惯这种直接的方式。后来我想,如果有专业书评,那对读者应该是很有裨益的。Amazon为什么能成为购书网站的No 1,高质量的读者评书就是其中的一大原因。台湾侯捷先生的《无责任书评》也是非常受欢迎的书评专栏,可惜现在侯先生专心创作,书评暂停,真希望有一天还能看到《无责任书评4》。

购书心得

选择书籍最重要的是看作者:一看他是否具有真正的水平;二看他是否能将技术阐释清楚。国内一些编书或者翻译的人对技术只是一知半解,又追求速度和效益,结果这种书只能是误人子弟。但水平高的人如果只有技术,没有写作和表达才能,或选材过于艰深,或文字晦涩难懂,也很难为读者接受。国内原创图书明显弱点是过于生硬,属于“冷面扑克型,不带任何感情,没有任何技术以外的润滑与承先启後的转折”(侯捷先生语),而且缺乏实用,看上去理论上面面俱到,可实际上却没有什么应用价值,所以国内几乎没有什么知名作者甚至译者,当然这也和出版大环境有关系。

台湾在这方面做得很不错,英文版技术书籍能很快翻译出版,同时也能出版较好的原创书籍。大陆出版界应该向他们学习,全国每年参加程序员水平考试的就有将近二十万人,以大陆人才之多、市场之广,出版社花心血出精品书籍,应该可以取得不错的销售业绩,同时对整个软件行业水平的提高也应该有很大帮助。

出版社“四大家”

国内有四家知名的电脑图书出版社:清华大学出版社、机械工业出版社、电子工业出版社和人民邮电出版社。本来希望出版社名声很大,是当年电脑图书出版的主力军,可惜现在只注重速度,太不重视质量,每况愈下,好好的一本《VC技术内幕》第五版,和清华出的《VC技术内幕》第四版相比,高下立判,所以对希望的书我现在有点敬而远之。

清华大学出版社作风严谨,一直保持比较高的水准。电子工业出版社是老牌出版社,曾经出版过不少好书名著,象《Windows 95编程奥秘》等等,但是最近有点止步不前。人民邮电出版社也出了不少书籍,特别是和台湾出版社合作较多,但技术书籍水平却不敢恭维。

和前三家相比,机械工业出版社是资历最浅的,不过却是步伐最快的。近几年引进的原版图书数量肯定排名第一,而且越来越重视质量,特别是最新出版的一批图书,有几个可喜的地方:

u 开始注重译者和翻译质量。译者来自各个大学,主要由教授博士担纲,翻译质量中规中矩,相当不错;

u 选材多样、覆盖面广。这批图书有TCP/IP详解 卷三:TCP事务协议、HTTP、NNTP和UNIX域协议》,《莱昂氏UNIX源代码分析》《Apache Server源代码分析》,《Linux内核源代码分析》《设计模式》,《软件需求》,《程序设计实践》,《Delphi 5开发指南》,《Windows核心编程》特别在网络编程和软件工程方面,都是十分精彩的名著;

u 提供了网站www.china-pub.com(中国互动出版网)支持。网站上大部分图书都有PDF格式的电子版,无论买书与否,用户都可以直接下载。

今天我想给大家介绍的是《设计模式》,这本书不厚(不到三百页),可是内容却很厚实。

《设计模式 可复用面向对象软件的基础》

《设计模式》的英文书名是《 Design Patterns: Elements of Reusable Object-Oriented Software 》。此书成名已久,实际上是1995年出版的,该书共有四名作者Erich Gamma Richard HelmRalph JohnsonJohn Vlissides,全部是博士,个个来头不小。该书堪称是面向对象设计的经典名著,一直名列Amazon销售排行榜,Amazon的读者综合评价达到了满分——五颗星,专家学者对《设计模式》也赞不绝口,书中扉页列出了它获得的赞誉:

“这本书是我长期以来所读过的写得最好的、最富洞察力的书籍之一——该书不是泛泛而论,而是结合实例,以最佳的方式确立了模式的合法地位。

--Stan Lippman, C++ Report

“这本众人期待的书的确达到了预期的全部效果。该书云集了经过时间考验的可用设计。作者从多年的面向对象设计经验中精选了23个模式,构成该书的精华部分。每一个精益求精的优秀程序员都应拥有这本《设计模式》。”

--Larry O’Brien, Software Development

《设计模式》在实用环境下特别有用,因为它分类描述了一组设计良好,表达清楚的面向对象软件设计模式。整个设计模式领域还很新,本书的四位作者也许已占据了这个领域造诣最深的专家中的半数,因而他们定义模式的方法可以作为后来者的榜样。如果要知道怎样恰当定义和描述设计模式,我们应该可以从他们那儿获得启发。

--Steve Billow, Journal of Object-Oriented Programming

总的来讲,这本书表达了一种极有价值的东西。对软件设计领域有着独特的贡献,因为它捕获了面向对象设计的有价值的经验,并且用简洁可复用的形式表达出来。它将成为我在寻找面向对象设计思想过程中经常翻阅的一本书:这正是复用的真实含义所在,不是吗?

--Sanjiv Gossain, Journal of Object-Oriented Programming

这本书虽然是五年前出版的,不过内容并不过时,软件工程的重要概念就是可复用。面向对象技术的发展使人们曾经设想会发明一种“软件芯片(software IC)”来满足软件开发的需要,但这种想法目前看起来还是太遥不可及了,而近几年来“模式”给出了“软件可复用”的漂亮解决方案。所谓模式一词来源于城市建筑领域,“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样,你就能多次使用该方案而不必做重复劳动。”这种思想应用在面向对象设计领域,指的是总结软件设计中遇到的各类问题,并提出设计的解决方案。

有经验的设计者知道,不是解决任何问题都要从头开始。这本书的目的就是将面向对象软件的设计经验作为设计模式记录下来,每一个设计模式系统地命名、解释和评价了面向对象系统中一个重要的和重复的设计。

《设计模式》共有6章,第一章介绍了设计模式的概念、描述格式和分类,解释了设计模式是如何应用解决问题,最后给出了选择和使用设计模式的很多建议。这一章是总览,需要和后面几章参照才能理解。

第二章通过设计一个所见即所得的文档编辑器介绍设计模式的实际应用,对设计中的问题列举了一个或多个设计模式的解决方案,并讨论了它们的优缺点。这个生动的实例充分显示了四位世界级专家作者是如何思考设计软件的。

下面的三章分类详细描述了23种常用的设计模式,给出了每种模式的设计意图、结构、使用效果、实现要点和缺陷、代码示例(SmallTalkC++)、在实际软件中的应用、相关模式等。这些模式分类如下表:

目的

设计模式

5种创建型

creational

Abstract Factory

Builder

Factory Method

Prototye

Singleton

7种结构型

structural

Adapter

Bridge

Composite

Decorator

Façade

Flyweight

Proxy

11种行为型

behavioral

Chain of Responsibility

Command

Interpreter

Iterator

Mediator

Memento

Observe

State

Strategy

Template Method

Visitor

最后一章总结了设计模式给软件设计带来的巨大影响。几年后的事实证明《设计模式》是近10年来最重要的软件开发书籍之一,《设计模式》给出的模式格式和词汇几乎成了软件设计的工业标准。

本书提供的23种设计模式看起来好像数目比较少,最新2000年出版的《The Pattern Almanac 2000》号称有700多种模式介绍。但实际上,模式数量不在多少,关键在于领会设计模式的思想,学以致用。本书作者之一John Vlissides曾经有一次举行演讲,他问听众中有多少人看过《设计模式》,几乎所有人都举手,他再问有谁能解释如何实现组合模式(23种模式之一),举手的人就寥寥无几了。这23种模式凝聚了作者的经验和心血。当你也开始在设计中考虑如何应用模式、如何使设计更简单更灵活、复用性更好时,你的实力就无形中提高了一个层次。

《设计模式》是每个软件设计人员的必备书籍。但我要说明的是这本书并不是一本容易读懂的书籍,有的专家甚至说一个开发人员需要花上一年时间才能领会这本书的精要。学习模式需要反复练习体会,才能应用自如。这有点象学围棋中的定式。围棋定式是百年来高手下法的总结,但不能简单地应用,要看场合选择合适的定式,还要按棋理会变通下法。

这本书不是读完就可以束之高阁的,只有具备相当基础的读者才能从本书获益,读者首先必须熟悉面向对象设计语言如C++或者Java,而且最好有开发和维护面向对象软件的经验,只有具备一些反面的设计经验才能充分体会设计模式的妙处。

该书的出版虽然比英文版晚了近五年,但总是从无到有,有了巨大的进步。据可靠消息,目前国内有几家出版社都在大力引进国外技术名著,在技术出版领域保持跟踪国外最新动态。这对于国内软件业整体水平的提高和发展大有益处,毕竟最新的软件技术和发展都来自于国外,希望今后的技术名著不再有这五年之差,也希望我国的软件业能走向海外。

展开阅读全文

软件开发最重要的是技术吗?

01-27

最近在写毕业论文,胡思乱想的东西多了些,看的东西也杂了一些。虽然我还没毕业,有些想法太过于理想化或太幼稚,但总觉得既然有想法还是写下来好,即使没什么用也聊以自娱。rn 最近一直在想的问题之一就是,软件开发到底是什么?软件开发最重要的是什么?是不是技术?也许是因为我本科学的是企业管理,很多事情不会单从技术的角度去看。rn 在网上搜一下,发现认为技术最重要的人还真是不少。很多人抱怨公司的管理人员不懂技术,造成技术人员在公司里没地位。也有不少人认为中国的软件企业为什么在国际上没有竞争力,为什么中国的软件行业上不去,关键是中国没有自己的核心技术。至于软件公司对技术似乎也是相当看重的,他们在招聘员工时第一标准就是技术,所谓的工作经验归根结底就是看应聘者的技术是不是熟练,是不是招来以后就可以干活,还是要再去培训一下。而现在公司对计算机专业大学生的抱怨主要也是大学生沉迷于游戏,不好好打基础,太过于浮燥,什么技术都学但什么技术都不精,面试时最简单的一些开发技术都不会等等,归根结底还是技术。这么看来,大家对技术都是挺看重的,为什么中国的软件业还是不行呢?rn 毕竟我是一个还在学校里的学生,所以我没有资格说中国软件业不景气的真正原因在哪里,甚至没有资格评价中国软件业究竟属于景气还是不景气。不过对于技术,我觉得技术确实相当重要。因为软件开发本来就是技术含量相当高的活动,任何一家不注重技术的公司都不会有很好的发展。而且望眼全球,应用最广泛的技术基本上都是那些第一流的IT大公司提出来的。在不懂技术的老板管理下的那些程序员的确相当可怜,度日如年,日夜不停地加班,但技术水平却上升不多,拿的薪水也可怜,即使拿了多也只能用来买些昂贵的保健品以补充体力,剩下的依然可怜。可程序员这么卖命,公司依然在亏,看来不懂技术的老板猛于虎啊!rn 于是就发现这样的一个问题:技术是很重要,大家也并不是不注重技术,而大家也相当努力工作了,为什么中国软件业的技术还是不行呢?看来软件开发并不是一个那么容易的问题,而技术也决不是软件开发的银弹。当然,《人月》都说了,根本就没有彻底解决软件开发各种问题的银弹。但我觉得至少应该存在缓和各种问题的铜弹吧!只是,恐怕技术不能扮演这个角色了。rn 我谈谈我对软件开发中什么是最重要的这一问题的看法。我不想扯到什么社会问题、民族劣根这些事情上,因为讨论这个没什么大的意义。我只是觉得,中国软件业似乎应该把技术从原有的至高无上的神殿上拉下来,这样大家才能心平气和地看问题。rn 首先,为什么那些技术天才不能救中国的软件企业?我觉得软件企业虽然是技术性质很强的企业,但归根结底是企业,应该从管理的角度来解决问题。而管理的同时,也要考虑到软件这一行业的特殊规率。如果一个管理者连自己行业的规率都不能把握,那他就不是一个合格的管理者,从这个角度上说,前文讲到的那种不懂技术的管理者其实连管理都不懂!rn 中国的软件从业者太过于注重技术了:程序员不停地去追求和学习那些新的技术,搞得身心疲惫;软件公司指望招来一些技术天才使公司的工作效率能有立竿见影的提高。可物极必返,你越是追求技术,你的技术越是提高得慢,甚至停滞。理由很简单,饭要一口一口地吃。软件开发是一项商品生产的行为,你必须先要调整好市场管理和生产管理甚至可能还有其它方面的问题,你对技术下的本钱才能升值。如果你只把技术当成救命稻草,招人时只要高技术的人员,其它的都不管不顾,结果当然是不理想的。rn 比如,现在的程序员工作强度很大,每天都在加班工作,当然一方面原因是一些黑心老板为了榨取程序员的精力,故意把项目的完成时间缩短,但开发效率低是一个最主要的原因。开发效率低主要是由于程序员大量的精力并没有放在代码的编写上,而是浪费在了除错上,浪费在了阅读和修改旧代码上,这点有经验的程序员应该深有体会。那么怎么解决这个问题呢?把现有程序员解雇再去招聘技术更好的程序员?这样做即使有效果也是微乎其微的,因为再好的程序员也难免出错。而且很多的时候高技术的程序员在这个问题上成事不足败事有余,一来越是高深的技术越是容易出错,二来高水平的程序员可能会和其它的程序员在水平上产生脱节,导致写出的代码过于精深别人看不懂影响交流,我在网上就看到过一个高水平的C++程序员由于在代码中使用了过多的BOOST库的内容,公司不得不请他另谋高救。第三,高水平的程序员的技术在项目中也许跟本用不上或没必要使用。当然这并不是说高水平程序员无用,关键在于这个问题并不是通过技术来解决的。要减少程序员浪费在除错上的时间(当然完全避免是不可能的),可以通过两种途径来实现,一种是减少错误的发生率,另一种是提高除错的效率。要做到这点就必须加强需求、分析、设计和测试的工作,并确保代码的质量。换句话说就是做好软件工程。(待续) 论坛

没有更多推荐了,返回首页