微软MVP
InfoQ中文站.NET社区首席编辑 朱永光
很早就在博客园上拜读过张逸的文章,尤其对他在设计模式方面的经验和见解印象深刻。在我把他邀请进InfoQ中文站编辑团队后,经过深入而频繁的交流,对他在整个.NET方面的学识和实践甚感佩服。尤其佩服于他深厚的文学功底,其能用优雅的文字把生涩枯燥的技术解析得浅显易懂。
理所当然,张逸在这本《软件设计精要与模式(第2版)》中,将用优雅的文字、贴切的比喻、精彩的示例为大家剖析设计的奥妙,分享他在.NET方面的丰富知识和经验。第一篇“设计之要”为目前流行的软件设计思想进行了提纲挈领;第二篇“.NET框架与设计模式”用我们每天工作的基础——.NET框架——作为最好的例子来讲解重要的设计模式;第三篇“媒体播放器的设计之旅”可以说是设计之要的完整实战演示;第四篇“设计模式应用实践”用一些与工作息息相关的实例展示设计模式的妙用;第五篇“.NET体系架构”则指引我们进入.NET应用程序架构的殿堂。
对于架构与设计模式,一直以来也是我最感兴趣的技术领域。而面向对象、设计模式、重构、测试驱动开发、敏捷编程这些思想,在我看来,即是武学中的各种秘籍,指引着我们修炼成为武林高手。但光拿到武学秘籍还不够,光勤学这些秘籍也还不够,还需要苦练其中的招数,并在一次次的比武中实践和体会。正如武学的最高境界是无招胜有招一样,软件设计的最高境界也最终是要把本书详细讲解的“招数”悉数忘记,让这些招数成为自己的习惯,自己的思维,在设计过程中自然而然地融会贯通——当然,这不是一朝一夕的事情。
通览本书,里面提到的很多思想和见解都能极大地引起我的共鸣。每当如此,常常会感叹自己没有足够时间和精力与大家分享类似的思想。因而,特意向大家推荐本书,一方面可以宽慰自己,更重要的一方面就是,很高兴张逸能给大家贡献这样一本软件设计的好书。
- 添加新评论
- 阅读次数:
InfoQ中文站(infoq.com/cn)总编辑霍泰稳
在InfoQ中文站.NET社区首席编辑朱永光介绍张逸,并希望邀请其加入编辑团队之后,我特别在网上找到张逸的相关资料研读,并粗略翻阅了他的著作《软件设计精要与模式》及译著《WCF服务编程》。一番考察之后,认为其符合InfoQ编辑人员所必备的两个特点:态度认真和技术扎实,然后郑重向其发出邀请。最终,张逸答应了我们的邀请,而我也为能和这样一位优秀的架构师合作而荣幸。通过其在InfoQ中文站上发表的作品,我和永光均为当初的决定欣慰,而张逸的作品也让网站.NET社区的内容更加充实。
很长一段时间以来,与模式相关的话题都特别引人注目。在去年InfoQ中文站举办的QCon北京大会上,来自知名网站eBay的架构师Randy Shoup介绍了eBay架构设计过程中的经验,场面之热烈,让很多参会者现在依然记忆犹新。今年Jolt图书大奖获得者Michael Nygard会带来他在系统设计过程中的反模式,虽未开场,已有多位朋友表示对此非常期待。诚然,在软件研发过程中,要找到一劳永逸的“银弹”并非易事,但类如“模式”和“反模式”这也的经验总结总会给后来者一些启发。
每个软件系统都有其独特的一面,研发所用的技术或者平台也多有不同,但仔细考察其背后的设计思想,总能发现几丝共性。而正是这些共性经过抽象之后,形成模式,然后被后来者不断传承和演进,使得我们的软件系统愈加庞大和健壮。希望通过本书,读者能够了解作者张逸对技术的真诚,也能够帮助自己在软件设计的道路上找到知音和共鸣。
- 添加新评论
- 阅读次数:
西门子中国中央研究院首席架构师
《软件架构的艺术》作者 李伟
张逸先生邀我为他的新著做序言,起初觉得难以应命。毕竟,一本书会成为很多人阅读学习的材料,并逐渐沉淀为社会文化的一部分而影响长远。长年的工程习惯告诉我,应该先认真阅读书稿,并且深刻理解书中鲜明的思想和观点后再下笔。但就个人目前的工作及精力,深感不能追求到如此完美的情景。然而,又意识到软件架构与设计工作对整个中国行业发展的重要和紧迫程度,决定借写序为契机,谈点关于架构和设计方面的点滴体会,做为本书的书序。
少年时代的我,充满了对科学的向往。儒乐.凡尔纳的科幻小说,把我带向了科学梦幻的世界,彷佛科学能够创造出美妙的未来世界。后来,对天文及天体物理的迷恋,把我强烈地吸引到了对伽利略、牛顿、爱因斯坦等伟人的崇拜。可笑的是,原想报考南京大学天文专业的我,被父母当头浇了一盆凉水。但是,一颗热爱科学的心一直在跳动。
整个大学的前两年,听课一直混混沌沌。直到大学三年级的时候,听了一位教授讲的数据结构课程,可以算是开启了我对计算机科学最初的认识。这是我第一次感知到计算机科学在很大程度上是研究人类智慧的学科,这也正是年轻的我所热望的专业!
毕业后,由于在国营单位这样的圈子中工作,又经历了一段混混沌沌。1992年后,面向对象的Borland C++ 及Turbo C++ 开始在世界乃至中国大陆范围内流行。半生半熟地阅读完这种全新的编程思想,仔细体会一番,又一次为人类智慧的结晶而震撼和赞叹。原来结构化的编程思想,虽然出自自然,但并不一定就是最好。人类居然可以模仿自然规律,来界定一个个关联的对象,可谓聪明和经典。
九十年代,是一个出国潮涌的时代,我也随着潮流,漂洋到北美。从那时开始,有两件事,真正把我从一个懵懵懂懂的年轻人,带到了计算机科学的智慧天堂。从而满足了专业工作人员的第一个要求,即知识的储备。
第一件是把自己所从事的研究工作,定位到了状态依赖的系统。这个方向的研究,彷佛打开了一扇大门,让我从只知道传统计算机科学的基础知识,加上有限的编程经验,真正地走向了专业知识的研究工作。进而使我深刻理解了国外为什么能够领先中国很多年,就已经能研发出很多严重状态依赖的实时系统。这也是我平生第一次,从软件系统的结构上,知晓了人类智慧的创造力。
另外,这个阶段也自然而然地接触到当时刚刚开始流行的Java这样相对纯净的面向对象编程语言所设计出来的一些系统。也很自然,工作中面对一个资深设计编程人员所设计出的模块结构和编写出的代码,科学之美的情感油然而生。期间,做为一个中国人,开始经常听到“架构”和“设计”这样两个有些陌生的词汇。最令我难忘的事,有个非常友善的同事,甚至还指导我去阅读一些有关架构和设计方面的知名著作。我也是从这个时刻开始,知道了Gang of Four的设计模式、Frank Buschmann(日后服务与西门子时,我的德国业务领导人)的架构和设计模式、Martin Fowler的著作……遗憾的是,由于当时自己所处工作环境的限制,没有能够更深入地体验出更多的东西,也没有一个合适的场合锻炼一下自己。庆幸的是,我已经比很多中国人早一些读到了一些经典的著作,学到了一些知识。
混混沌沌的我,在2003年底举家回到了祖国。当时的中国,正处于IT革命所带来的一片欣欣向荣的环境当中。由于是所谓的海归,自然有机会在这样的系统研发浪潮中冲锋在前,把自己一知半解的所谓经验使用到现实的系统研发工作中。着实轰轰烈烈的实践了一轮,却发现自己又一次迷失了:理论学习过了,实践也经历了,我该走向何方?
糊里糊涂地,无意间读到了一篇纪事报告,题目叫《最后的大师》。此文的作者是应钱学森先生的邀请,来记录自己的导师,清华大学物理系及清华大学创始人之一的叶企孙先生。叶先生早年在美国留学期间,在物理方面做出过杰出的贡献。虽然大多数后人并不知道叶先生,但是他的学生没有一个会忘记他,这包括三钱、华罗庚、李政道、杨振宁等等。可以这样说,你所知道的中国大师,大多都是他的学生。阅读完此文,颇受启发:真可谓“大师培养大师”。我非常欣赏这句话。既然我身边没有大师,就应该认真回味一下自己这些年来的学习和实践,看看是否能将既有的种种知识和经验,上升为智慧。毕竟,智慧是指导我继续工作的原始动力,并指导自己未来的创新工作。因此,我选择了阅读、学习和思考。
自己成长的这段历史,算是翻过去了。再回到张逸先生的这本《软件设计精要与模式》上来,我虽作粗略阅读,但从实践分享的视角来看,书的内容编写地非常认真。作者从自身工作的经历,分享了自己对软件设计的理解,并以设计原则这样的方式,来分享最宏观层面上的要点。总结、思考的分量,可见一斑。本书有些章节很有新意,注意到了利用自身实践过的设计模式,以真实示例的方式来介绍如何灵活使用各种设计模式。此举对读者的实际工作,颇有帮助,愿为推荐。
其实,个人成长的历程,也在一定程度上代表了中国专业从业人员的成长轨迹。中国正在面临一次深刻的变革,需要更多优秀的编程人员,优秀的设计人员,优秀的架构人员,优秀的创新人员。毕竟,一个要立足于世界之林的强国,急迫地需要能把事情做得精彩和经典的行动人员。
谨记所感,提供讨论。

2010年2月12日北京
- 添加新评论
- 阅读次数:
我希望告别冗长的前言,仅述说第二版的变更。写作第二版的我,疯狂地吸收了诸多大师的设计思想,这一点可以从参考文献的前后差别看到端倪。这两年以来,我又参与了几个项目的设计与开发工作,所谓“实践出真知”,在佐证大师观点的同时,自己对设计的认识更进了一步。或许,第二版不会比第一版优秀太多,但至少会减少诸多不足。囿于版本,我无法做出新的突破。我期待能创作一本全新的书,全面论述我对软件设计的认识。现在的我,还不足以写出梦想中的软件设计之道。
言归正传。
整体而言,我对第一版的所有章节都进行了一定程度的修订。或者更正了过去的错误,或者进一步完善了原有内容。本书的内容仍然是散漫而自由的,然而形散而神不散,大体遵循了设计的基本原则。
在第一篇《设计之要》中,我新增了《对象法则》一章,言简意赅地介绍了面向对象思想的核心要素与设计原则。这基于我的一贯理念,即设计模式的核心本质是面向对象设计思想的运用。只有掌握了面向对象设计思想,才能真正体会设计模式的精髓,并将其运用在实际的项目开发过程中。《对象法则》一章可以有机地与《封装变化》一章结合起来,再加上第23章《软件体系架构》的内容,基本上勾勒出软件设计的脉络,从面向对象思想到设计模式,再到软件体系架构。
在《封装变化》一章中,我不仅完善了项目实例,还增加了关于如何“解耦具体依赖”的几种技巧。对于软件设计而言,这是非常有益的指导。我整个儿删去了第一版的第5章《设计,由你掌握》,并将其中的部分内容转移到《封装变化》一章中。这使得第一篇的内容更为紧凑,虽然删去了讨论极限编程的相关内容,却可以使得我们能够更加关注于设计,而不是方法学。
第二篇《.NET框架与设计模式》增加了对.NET 3.X的源代码分析。我无法做到与时俱进,因为.NET 4.0即将走进.NET开发人员的程序生活。或许在本书出版之后的不久,还会有5.0,6.0……我只是希望我的书不要被时代抛弃得太远。好在设计模式本身属于经典,而经典总是能够经得起时间考验的。本书讲述经典,自然能讨得一定好处。
更新最明显的是迭代器模式在.NET中的实现。C# 2.0引入的yield return以及.NET 3.0引入的Lambda表达式都为迭代器模式在.NET中成为一种惯用法贡献了一份心力。我对此的分析,可以在一定程度上帮助读者更好地理解迭代器模式。在第二篇中,我新增了一章《.NET中的命令模式》,通过解析.NET 3.0引入的WF(Windows Workflow Foundation),展现命令模式的非凡价值。第二篇的内容虽然与.NET平台息息相关,但对于其他平台的开发人员而言,仍有可观之处。我在撰写本书第二版时,同样参考了Java平台的设计理念,以及Ruby中的设计模式。
从章节名称来看,我对第三篇《媒体播放器的设计之旅》进行了颠覆性的革新。事实不然,虽然内容仍有调整,但并未动摇其根本。在对本篇进行修订时,我扮演了一名重构者的角色,利用重命名和搬移内容的方法,极大地改善了既有章节的合理性。我抛开原有的以设计模式为核心的论述方式,转而从软件设计的角度看待问题。模拟真实的软件开发,我讨论了如何运用面向对象设计思想,如何对接口进行分离。当客户需要引入第三方软件时,我提出了接口适配的方案。当需求发生变化时,我则对接口行为进行了扩展或装饰。
第四篇《设计模式应用实践》仍然体现了本书的重要价值。我对第18章《命令模式应用》的实例进行了极大地完善,使得该实例在表现命令模式方面,更加丰富与完整。第19章《职责链模式应用》完全面貌一新,替换为最近完成的一个项目实例,并通过对领域进行建模,辅以用例图、时序图、通信图和类图推导详细设计,展现了“用例驱动开发”设计思想的冰山一角。
本书对软件架构着墨不多,主要的架构思想均放在第五篇《.NET体系架构》中。利用PetShop实例,对于指导读者初窥架构之美,仍有不可低估的作用。第二版对软件体系架构的内容有所补充与增强,更多地引入了企业应用架构模式和领域驱动设计的内容。第23章《软件体系架构》算得上是技术架构的入门读物,主要介绍了分层架构模式与相关设计要素。在第24章《数据访问层》中,我特别引入了.NET 4.0中的Entity Framework,算是一次有益的尝鲜。利用这样的ORM框架,还可以极度方便地实现资源库模式与工作单元模式,在诸多分层架构中,我们都可以看到它们的身影。在第28章《表现层》中,我设想了如何在PetShop中引入ASP.NET MVC框架。我本希望能有大量篇幅介绍Silverlight,以及MVP模式的运用,如此对于.NET的表现层设计方才显得完整,可惜我对Silverlight所知不多,心有余而力不足。
第二版还有诸多变化不能体现在目录中。例如我对本书的全部设计图进行了更新,更加准确、完善和美观,并保持了图形风格的一致性。第二版加入了诸多注解,大多数内容都是正文的补充与扩展,乃至思想点滴。阅读这些注解,可以帮助读者更好地理解我的设计意图,获得更多的模式知识。
本书面对哪些读者?读者又该如何阅读本书?第一版前言已经给出了答案。本书的再版并不打算彻底地改头换面。除了致谢,我不打算重复唠叨了。
钱锺书先生认为,献书仿佛魔术家玩的飞刀,放手而并没有脱手。随你怎样把作品奉献给人,作品总是作者自己的。可我还是希望把本书献给我的孩子——子瞻。当他宁静地呆在母亲肚子里时,本书的第二版同样也在孕育之中。现在,子瞻已经过了周岁生日,没有什么礼物可以比得上这本书更让我感到自豪。我还要把本书献给我亲爱的妻子。写作虽然痛苦,可哪里及得上你分娩痛楚的万分之一。抚养子瞻的辛劳,更让虚弱的你身心憔悴。本书献给你,可否给你一丝安慰?
感谢我的父母。尤其感谢我的母亲。这一年多以来,调皮的子瞻折磨得您腰酸背痛,您却没有任何怨言,反而甘之如饴。我能有时间写作本书,您功不可没。
- 添加新评论
- 阅读次数:
在我看来,我从第一版出版之后得到的读者反馈实在是有限。除了有少数几位细心的读者给我指出书中的错误之外,大体上就都是泛泛而谈了。这对本书第二版的写作带来一些障碍。因为我无法知道读者对每一章的评价,不知道哪些章节对大家有益,哪些章节还有不足之处。我只能根据自己的经验来揣摩读者的想法,对第一版的内容进行改善。同时,在新版中增加第一版出书之后所获得的新知识与新认识。第二版在风格上仍然沿袭了第一版的特色,但内容无疑更加丰富。
在第一篇《设计之要》中,我会增加两个新的章节,分别介绍面向对象思想与设计原则,以及领域驱动设计。同时,删去原书的第5章《设计,由你掌握》。增加的这两章,前者是讲解设计基础,而后者则会以一个完整的案例为读者展现领域驱动设计的要点、宗旨、原则和相关思想。第五章的部分内容会合并到原书第1章《设计之道》与第2章《封装变化》之中。此外,我会极大地丰富第1章的内容,企图通过这一章为读者全面介绍软件设计的相关思想与技术。对于《封装变化》一章,我修订了一些小小错误,同时增加了“封装对象结构变化”一节。关于解除具体耦合,原书只是简单介绍了依赖注入。第二版不仅会深入介绍依赖注入,还将增加注入表驱动法、惯例优于配置、服务***等模式与方法。对于原书第3章和第4章对于重构和测试驱动开发的介绍,我准备更换一下演示的案例。尤其是重构一章,关于数学容器的设计实在太过于简单了。
第二篇《.NET Framework与设计模式》在第一版是针对.NET 2.0进行分析的。在第二版会针对最新的.NET框架进行分析。这一篇的变动不会太大,但可能会增加一些在.NET框架中的设计模式分析。目前,我已经完成了第6章《Factory Method模式》和第7章《Composite模式》的修改。我修改了第6章的Factory Method模式的例子。而在第7章,我则改善了原有的设计,使之更加完美和优雅。
第三篇《媒体播放器的设计之旅》的变化或许会比较大。因为我会开发一个真实的媒体播放器,用以演示各种模式的运用。因此,可能会增加几种模式的运用,不过关于第一版中讲解Adapter模式的章节,则可能会删去。
第四篇《设计模式应用实践》仍然沿用旧有的风格。我会对第17章的Builder模式案例进行调整,因为本章的案例对于Builder模式的应用还不够典型。第18章《Command模式应用实践》的案例不会改变,但我会进一步完善它,尤其是充分利用Command模式的特性。第19章《Chain of Responsibility模式应用实践》写得过于矫情,我可能会考虑删去它,也可能会用另外的案例代替。经读者提醒,第21章《Proxy模式应用实践》存在一个小小的错误,我会在第二版中对其进行修正。第22章《复合的设计模式实践》思想是好的,但明显有过度设计的嫌疑,且设计思路并不够好。我会考虑对其进行大的手术。此外,我可能还会增加一些章节,不过具体有哪些,我现在还说不清楚。
第五篇《.NET体系架构设计》叙述的内容以现在看来,过于陈旧了。我会在其中适度地增加体系架构设计的相关知识。最关键的是,第二版不再以PetShop作为讲解的模板,拟考虑对DinnerNow(或者StockTrader)进行分析。在这一篇中,会增加对LINQ、WCF、WF等知识的介绍。当然,介绍的思路与结构不会发生太大的变化,仍然以分层式架构作为主体框架。
- 添加新评论
- 阅读次数:
距离《软件设计精要与模式》的出版已有两年多的时间,从出版之初的热销到后来归于平淡,我也经历了从兴奋期到蛰伏期的过程。这本书的反应不算好,也不算坏。在浩瀚如大海一般的书市里,就好似一滴水珠融入大海,冒了一个小小的泡儿,然后就被波涛给淹没了。不过,这滴水珠对于我而言还是非比寻常,我不能完全漠视。这两年多以来,也陆续参与了一些项目,并负责了项目的架构设计。这期间,我又广泛的阅读了大量书籍,其中主要关注的还是软件设计。这段时间的积累,方才发现当初的想法还是过于稚嫩。这本书囿于我当初的水平,不免存在许多疏漏,甚至错误。我一直在想,如果我能够重头再来,我应该会写得更好。
出版社对于本书还是抱着正面的态度(坦白说,读者的反馈大体是还是正面的),但我不能就此满足,我希望能精益求精。去年年底,我到北京参见WinHEC大会,有机会和本书的责任编辑胡辛征先生相聚。我们就此谈了本书出版第二版的相关事宜。回来之后,我忽然开始贬低我的这本处女作了。“要么,推倒重来!?”我心中产生了一种大胆的想法。
于是,我开始了未雨绸缪,心里为自己制订的计划,也是抱着创作新书的目标。我希望自己能够阐述软件设计的本质,而不是仅仅对设计模式的展示与阐述。这对于我而言,是一项巨大的工程。唯一可以凭借的是我曾经拥有的设计经验、设计模式的培训经验以及技术书籍的创作经验。几个月的准备时间,让我积累了大约4万余字的读书笔记与心得体会。但我却迟迟不敢动笔。我对软件设计越了解得多,感觉到自己的不足就更加的深刻。我需要厚积薄发。
实际上,创作新书的想法还在于自己被刺激了。《软件设计精要与模式》一书虽然没有沦落到蒙尘的地步,但销售并没有达到我的期望。这就意味本书没有得到更多的认同。今年4月,我参加了QCon大会。在大会期间,我有幸认识了很多技术界的大师级人物,深入了解了他们的经历与思想。我觉得自己的眼界豁然开朗了。我觉得自己不能过于拘泥一时之得失。
不久之前,宁波大学的一位老师给我发来Email,说他准备选用我的书作为他们的教材。可惜现在购买不到,所以写信询问购书事宜。我于是查询了网上书店,果然发现我的书在诸如当当书店、China-Pub等处已经缺货了。询问了出版社,结果出版社的库存也没有了。基本上可以说,《软件设计精要与模式》一书已经售罄。这对于我来说,无疑是一个安慰,同时也为我打了一针强心针。
站在市场的角度,现在是创作本书的第二版的好时机。但最关键的还是我有了这样的信心和愿望。我想,我可以尽自己最大的努力来完善本书。现在,我又该踏上《软件设计精要与模式》第二版的征途了。至于我计划的新书,看来又得往后推移了。
- 添加新评论
- 阅读次数:
本文为《软件设计精要与模式》第十七章
在GOF 所著的《设计模式》一书中,描述了Builder模式的意图:“将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。”按照封装变化的原理,Builder模式实则是封装对象创建的变化,但它与Factory Method模式、Abstract Factory模式不同的是,所谓对象的创建,主要是指对象内部构件的创建。形象地说,Builder模式就好似生产线的装配工人,可以接收多种方式与顺序组装各种零部件。本章,将给出我参与设计与开发的CIMS系统中的一个需求,详细讲解Builder模式的应用。
- 添加新评论
- 阅读次数:
本文为《软件设计精要与模式》第四章
在企业运营理论体系中,有一种理论叫做运行价值链。它将企业的运营分为三个步骤:首先是发现价值,找到目标市场;然后是生产价值,将高质量的产品生产出 来;最后是保护价值或收获价值,保证产品的质量,做好品牌。我们应该如何理解运行价值链呢?以nike为例,在nike鞋的企业运行过程中,首先是设计 nike鞋,也就是运行价值链中的发现价值。在这个过程中,可能收获50美元的价值。然后是生产。nike公司为了降低成本,会将生产基地设在劳动力成本 较低的国家,例如中国进行生产。这其中的价值大约是10美元。最后,再将生产好的鞋子,贴上nike的商标后送回到美国本土进行销售,又可以收获40美元 的价值。一双鞋利润100美元,而生产价值所能收获的却仅有10美元。这一步获取利益最低,但我们中国本土的公司却做得最好;而对于如何去发现价值,然后又怎样去巩固自己的品牌和知名度,中国的公司就只能说是差强人意了。
- 添加新评论
- 阅读次数:

Juval Löwy的《Programming WCF Services》(本书中文版名为《WCF服务编程》,张逸、徐宁译,2008年1月由机械工业出版社出版)可以说是微软WCF技术书籍的开山之作。我在本书的译者序中这样写道:“它全面准确地为我们描绘了一幅WCF画卷的清明上河图”。这句话也成为了机械工业出版社为本书造势的宣传语。随着《Programming WCF Services》中文版在国内的出版,有关WCF的书籍也如雨后春笋一般涌现出来,其中不乏出类拔萃者,但却始终无法撼动《Programming WCF Services》在众多WCF技术书籍中的独特地位。是的,本书并非剖析WCF本质的煌煌巨著,例如像Don Box的那本不朽著作《Essential Com》。同样还有一本讲解技术本质的,除了Don Box的另一本著作《Essential .NET》之外,我还拜读过Dharma Shukla与Bob Schmidt所著的《Essential Windows Workflow Foundation》。必须承认,在WCF技术领域内,目前还缺乏这样一本分析技术本质的佳作。然而不可否认的是,对于WCF技术的推广而言,只有《Programming WCF Services》这样类型的书才是最佳选择。因为它“不仅具有高屋建瓴地体系架构知识,同时又能够细致入微地观察技术细节,然后用深入浅出的语言打造成通俗易懂的著作。就像清明上河图一般,巨细靡遗,浑然天成。”
- 添加新评论
- 阅读次数:
软件设计最大的敌人,就是应付需求不断的变化。变化有时候是无穷尽的,于是项目开发就在反复的修改更新中无限期地延迟交付的日期。变化如悬在头顶的达摩克 斯之剑,令许多软件工程专家一筹莫展。正如无法找到解决软件开发的“银弹”,要彻底将变化扼杀在摇篮之中,看来也是不可能完成的任务。只有积极地面对“变 化”,方才是可取的态度。极限编程(Extreme Programming,XP)的倡导者与布道者Kent Beck提出要“拥抱变化”,从软件工程方法的角度,给出了应对“变化”的解决方案。如果从软件设计方法的角度出发,要在开发过程中应对未来可能的变化, 解决之道则是——封装变化。
- 添加新评论
- 阅读次数:






张逸(Bruce Zhang)
