软件设计启发法之——寻找模式

只要在软件行业干了几年，应该都听说过「设计模式」，并且在项目中也见到过。

但可能并没有真正实践过，因为「知道并不等于做到，更不等于能做到」。

认识设计模式

设计模式提供了一种现成解决方案的核心，可用于解决软件开发中的许多最常见问题。

大多数问题跟过去问题很相似，那些问题可以被相似的解决方法或模式解决。只有少数一些软件问题需要从第一性原理（first principles）派生出的解决方案解决。

常见的设计模式包括：

适配器模式（Adapter）、桥接模式（Bridge）、装饰器模式（Decorator）、外观模式（Facade）、工厂方法（Factory Method）、观察者模式（Observor）、单例模式（Singleton）、策略模式（Strategy）和模版方法（Template Method）。

著名的《Design Patterns》一书中有对各个设计模式的明确描述。

设计模式带来的好处

依据模式进行设计提供了完全自定义设计所没有的几个好处：

好处一：模式通过提供现成的解决方案降低了复杂性

如果你说：“这个代码使用了工厂方法（Factory Method）创建派生类的实例。” 同项目组的另一个程序员将会理解你的代码涉及一组相当丰富的相互关系和编程协议，当你引用工厂方法的设计模式时，所有这些方法都将被调用。

工厂方法是一种模式，它允许你实例化从特定基类派生的任何类，而无需跟踪除工厂方法之外的任何位置的各个派生类。

对工厂方法模式很好的一个讨论可以参考《Refactoring 》（中文《重构》）一书中的第十章12小节：Replace Constructor with Factory Method（用工厂方法替换构造函数）。

你不必为其他程序员阐明每一行代码，去理解你的代码中的设计方法。

好处二：模式通过将常见解决方案的细节制度化减少了错误

软件设计问题包含只有在问题被解决一次或两次（或更多次）才能完全显现的细微差别。因为模式代表了解决常见问题的标准化方式，它们体现了多年来试图解决这些问题所积累的智慧，也体现了对人们在解决这些问题时所作错误尝试的纠正。

因此，使用设计模式跟使用库代码而不是写自己的代码在概念上是相似的。当然，每个人都写了几次自定义快速排序（Quicksort），但是你自己的版本有多大概率在第一次尝试的时候就完全正确呢？

同样，许多设计上的问题与过去的问题非常相似，因此最好使用已有的设计解决方案，而不是重新创建新颖的解决方案。

好处三：模式通过建议设计备选方案来提供启发式价值

一个熟悉常见模式的设计者可以很容易的浏览模式列表，并且问“这些模式中的哪一个适合我的设计问题？”

在一组熟悉的设计替代解决方案中不断比较选择，比从头中创建自定义设计解决方案要容易得多。

从相似的设计模式中产生的代码也将会比完全自定义的代码让读者理解起来更容易。

好处四：模式通过将设计对话移动到更高层次来简化沟通

除了设计模式带来的复杂性管理的好处之外，它还允许设计者在更大的粒度级别上进行思考和讨论，从而加速设计讨论。

如果你说：“在这种情况下，我无法决定我应该使用创建者（Creator）模式还是工厂方法（Factory Method）模式。” 你只用几句话就沟通了很多——只要你和你的听众都熟悉这些模式。想象一下，你需要花多长时间才能深入了解创建者（Creator） 模式的代码和工厂方法（Factory Method）模式的代码，然后比较和对比这两种方法。

---

当然，使用设计模式也得小心

陷阱一：强制让代码符合某种设计模式（ force-fitting code to use a pattern）

在某些情况下，稍微移动代码以符合公认的模式将提高代码的可理解性。

但是，如果代码偏移得太远，那么强制它看起来像标准设计模式有时反倒会增加设计复杂性。

陷阱二：为了模式而模式（feature-it-is）

在这种陷阱中，使用模式是因为想要尝试设计模式，而不是因为模式对现有的软件问题是一个合适的设计解决方案。

这样做不能充分利用设计模式带来的种种好处，反而会使系统的复杂性增加。

最后

总之，设计模式是管理复杂性的一个强有力的工具。

以上仅作为笔记，内容来自《Code Complete 2: A Practical Handbook of Software Construction》一书。

上面的内容看起来很可能有点奇怪，如果可以阅读英文的话，还是建议去找到原版书读，其实英文原文确实是很有趣的！