PDF《设计之道》

虽然目前的需求是整数,他们可能想到今 后可能会扩展到实数,甚至于复数.他们希望能利用某种设计,使其具有更好的扩展性.从 眼前的需求来看,可能是过度设计;

然后对于未来,这个设计才是最完美的方案. 问题不在于设计是否过度,关键还是在于设计的理念.是只做目前需要的事,还是未雨 绸缪, 想好今后的功能扩展?这个问题的答案还需要实际的项目开发来检验, 根据不同的需 求,答案会因此而异. 需要设计模式吗? 答案是肯定的, 但你需要确定的是模式的应用是否过度?我得承认, 世界上有很多天才 的程序员,他可以在一段代码中包含

6 种设计模式,也可以不用模式而把设计做得很好.但 我们的目标是追求有效的设计,而设计模式可以为这个目标提供某种参考模型、设计方法. 我们不需要奉 GOF 的设计模式为圭臬,但合理的运用设计模式,才是正确的抉择. 很多人看过 GOF 的《Design Patterns》 ,对这

23 种模式也背得滚瓜烂熟.但重要的不是 你熟记了多少个模式的名称,关键还在于付诸实践的运用.为了有效地设计,而去熟悉某种 模式所花费的代价是值得的, 因为很快你会在设计中发现这种模式真的很好, 很多时候它令 得你的设计更加简单了. 其实在软件设计人员中, 唾弃设计模式的可能很少, 盲目夸大设计模式功用的反而更多. 言必谈 模式 ,并不能使你成为优秀的架构师.真正出色的设计师,懂得判断运用模式的 时机. 还有一个问题是,很多才踏入软件设计领域的人员,往往对设计模式很困惑.对于他们 来说,由于没有项目的实际经验,OO 的思想也还未曾建立,设计模式未免过于高深了.其实,即使是非常有经验的程序员,也不敢夸口对各种模式都能合理应用. 重构是必然的! 既然我们无法给出一个完美的设计方案, 因为客户的需求总是变化的, 重构也就成为必 然.问题是,这样没有添加任何功能的重构,你是否愿意为此付出精力、时间去完成.当客 户要求的 Deadline 将要到来的时候,你还认为你的重构工作是必要的吗? 有时候,软件设计常常身不由己.然而,纯从技术的角度来看,重构非但必然,而且重 要.既然我们都明白,复杂的未尝就是好的,简单的也不一定是容易的.要保持你的设计尽 可能的简单,可能你还需要时时借助重构的利器,来 改善你既有代码的设计 . 对于重构,Martin Fowler 给出了很多条款.这些条款并不是政治课本的教条,也不是 日月神教 的神奇咒语,念着它们就可以防身.这些条款确实很重要,但你需要的是学会 他后,然后忘记他,就象张无忌学太极拳那样.我不是故弄玄虚,事实上只有这样,重构的 精神才能完全融入到你的设计中. UML 重要吗? 我现在看一个设计方案的时候,更希望先看看 UML 图,然后再看文档的实际描述.如 设计之道 -

4 - 果让我读一段代码,我希望能先看看类图,或许更容易理解代码的含义.UML 在OO 世界 里像是世界语,它便于程序员间的交流,让别人更容易理解你的意图.同时,在设计 UML 图的过程中,也是一种对思路的清理,对客户需求的把握,设计思想的跟踪. UML 是一种基于对象的统一建模语言,它能够为系统设计提供清晰直观的设计.在面 向对象世界里,UML 的地位弥足轻重,甚至被称为是软件设计的一场革命.对于有计划的 设计,UML 的价值就体现得淋漓尽致.如果我们要清晰地表现模块的功能,模块间的关系 和系统分布的层次, 使用 UML 可以使设计师减少很多麻烦, 同时降低了语义描述的二义性. 然而,如果我们在做演进的设计时,UML 还有那么重要吗?我们只需要对眼前的需求进行 编码、测试,然后重构.可能我们只需要在 Pair Team 中讨论设计方案,在预定技术框架内 探讨实现的可能和细节.我们完全可以抛开 UML 繁琐而死板的设计,毕竟最能忠实体现设 计思想的,不是文档,不是用例图或是什么类图,而是代码. 那么,有多少人是这样想的? TDD、单元测试和其他 软件的生命是什么, 是质量! 而保证质量的唯一方法, 就是测试. 传统的软件开发过程, 强调首先进行需求分析,再从需求分析中抽象出概要设计,进而作出详细设计,然后编码, 最后才是测试以验证代码的正确性.而测试驱动开发(TDD)改变了编码的过程,开发仅 仅包括三方面的活动:编写测试用例,编码并进行测试,重构代码以消除重复代码使其更简 单、更灵活、更容易理解.通过测试来驱动开发,听起来是那么的离经叛道,然而实施起来, 又是那么合理、正确和简单,前提是:我们不能在一开始就获得正确的设计!TDD 避免了 对不完整需求造成的不成熟的设计.通过单元测试,保证了代码的正确性与高质量;