设计之道

设计之道设计之道张逸著

1设计之道-1-目录设计，看上去很美.................................................................................2设计，由你掌握.....................................................................................5重构初体验........................................................................|...................20从企业的运行价值链说起....................................................................28使用极限编程改善项目的设计和灵活性............................................34从实例谈OOP、工厂模式和重构.......................................................45从实例谈Adapter模式................................|.........................................52从Adapter模式到Decorator模式.......................................................57Visitor模式之可行与不可爱................................................................63从容自若的CTO......................................................................|............68Strategy模式的应用实践.....................................................................75FactoryMethod模式.............................................................................81Composite模式.............................................................................|........92Iterator模式........................................................................................104

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

3设计之道-3-我们还要考虑软件的性能|、扩展性，模块间的耦合关系，系统的稳定、部署和更新，版本的管理，系统的安全，界面的友好程度。要想简单，何其之难！Dothesimplestthingthatcouldpossiblywork!这是XP人士大声疾呼的口号，我也举双手赞成。问题是，我们需要让简单的事情，同时又有效。很多人在设计时，并不满足于实现眼前的功能。看到加法，他们可能还会想到乘法；虽然目前的需求是整数，他们可能想到今后可能会扩展到实数，甚至于复数。他们希望能利用某种设计，使其具有更好的扩展性。从眼前的需求来看，可能