PDF《设计之道》

设计之道 设计之道张逸著设计之道 -

1 - 目录设计,看上去很美

2 设计,由你掌握

5 重构初体验.

20 从企业的运行价值链说起.28 使用极限编程改善项目的设计和灵活性

34 从实例谈 OOP、工厂模式和重构

45 从实例谈 Adapter 模式.52 从Adapter 模式到 Decorator 模式

57 Visitor 模式之可行与不可爱.63 从容自若的 CTO

68 Strategy 模式的应用实践

75 Factory Method 模式.81 Composite 模式.92 Iterator 模式

104 设计之道 -

2 - 设计,看上去很美 设计没有标准,模式充满变化,我们对设计与模式的探讨,就是希望能从没有标准的设 计中体验设计的乐趣,从充满变化的模式中寻求问题的解决之道. 我这里所谓 设计没有标准 ,其实并非没有标准,现实是设计的标准实在太多了.我 们都希望找到最好的设计方案,然而什么是最好,每个人都有自己的 哈姆雷特 .满足客 户需求的设计就是最好的,这个结论我想不会有人反对,前提是,怎样通过设计来满足客户 需求? 计划的设计和演进的设计 通常来说,软件设计不外乎两种方式:计划的设计和演进的设计.很多人看来,计划的 设计更符合工程学的理念.如果你要建一间茅屋,那么你只需夯好土墙,再胡乱堆放一些茅 草置于屋顶之上就可以了.然而,如果要你建一座苏州的拙政园,就必须事先有计划的设计 了.哪里应该堆放假山,哪里应该开辟池塘,亭子的形状,院落的分布,乃至于园内的一花 一木,无不需要独具匠心.软件设计也是如此,且过之而无不及.接手项目的时候,首先考 虑的不是编码,而是考虑整个系统的架构,根据需求考虑系统中的重大问题.模块的功能, 模块间的关系和系统分布的层次,都需要匠心独运,从一个抽象的层面来考虑. 演进的设计恰好与之相反, 它是一种渐进的过程. 它并不要求前期的设计有多么的完美, 实现的需求有多么的完整,你只需要把现阶段考虑的问题编码实现就可以了, 随着演进的深 入,编码也会随之而修正,最后设计会逐渐丰满起来,经过一系列的方法,最后的设计也渐 趋完美. 你也许会认为 演进的设计 如此的简陋与平庸.没有计划,只会令设计一团遭.但我 需要提醒你的是,虽然都是工程学,软件的设计并没有建筑设计那么简单.因为,你很难在 设计之初,考虑到客户的全部需求,甚至于实现未来的扩展.在设计一开始,你能确信: 你对客户的需求都理解了吗? 你能确定客户的需求不再变化吗? 你设计的软件架构真的能满足需求吗? 是的,你无法给出肯定的回答.总之我在这里不是想说服每个人,要采取哪一种设计方 式.事实上,我也面临抉择的困难. 过度设计,还是简单设计? Kent 在《解析极限编程――拥抱变化》中为简单系统制定了四个评价标准,依次为(最 重要的排在最前面) : 通过所有测试;

体现所有意图;

避免重复;

类或者方法数量最少;

这些标准写出来简单,要根据这个标准来实现,就不是那么容易的事了.我相信,软件 设计人员都希望自己的设计尽可能简单.然而,在设计时,我们不仅仅要考虑软件的功能, 设计之道 -

3 - 我们还要考虑软件的性能、扩展性,模块间的耦合关系,系统的稳定、部署和更新,版本的 管理,系统的安全,界面的友好程度.要想简单,何其之难! Do the simplest thing that could possibly work! 这是 XP 人士大声疾呼的口号,我也举双 手赞成.问题是,我们需要让简单的事情,同时又有效.很多人在设计时,并不满足于实现 眼前的功能.看到加法,他们可能还会想到乘法;