关于”设计模式” (about Design Partterns)

什么是设计模式? 设计模式的重要性? 怎么使用设计模式? 在这里您将得到解答…

转自: 代码大全2

     Look for Common Design Patterns
     查阅常用的设计模式

     设计模式精炼了众多现成的解决方案，可用于解决很多软件开发中最常见的问题。有些软件问题要求全新的解决方案，但是大多数问题都和过去遇到过的问题类似，因此可以使用类似的解决方案或者模式加以解决。常见的模式包括适配器（Adapter）、桥接（Bridge）、装饰器（Decorator）、外观（Facade）、工厂方法（Factory Method）、观察者（Observer）、单件（Singleton）、策略（Strategy）及模板方法（Template Method）。由Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides所著的《设计模式》(1995)一书是讲述设计模式的最权威著作。

     与完全定制的设计方案相比，设计模式提供了下列益处。

     设计模式通过提供现成的抽象来减少复杂度  如果你说，“这段代码使用Factory Method来创建派生类的实例，”那么你项目中的其他程序员就会明白，这段代码涉及到了一组相当丰富的交互关系以及编程协议。在你提及到了Factory Method这个设计模式时，所有相关的信息都被唤醒了。

     Factory Method是一个模式，它允许你在对一个特定基类的任意派生类做实例化的时候无须关注具体派生类的情况，除了在Factory Method内部。你可以在《重构》（Fowler 1999）一书的“用工厂方法取代构造函数”一节里看到关于应用Factory Method的不错的讨论。

     你不需要把你代码中的设计思路逐行地讲解给其他的程序员，他们就可以理解你的代码里的设计思路。

     设计模式通过把常见解决方案的细节予以制度化来减少出错  软件设计问题中总包含着一些比较微妙的地方，只有当它们被解决了一两次（或者三四次甚至更多）之后才能完全显露出来。因为设计模式代表了一些解决常见问题的标准做法，积聚了多年来人们尝试解决那些问题的智慧，同时也包含着对人们在解决这些问题时所犯错误的更正。

     如此看来，应用设计模式和“用程序库取代自己编写的代码”在概念上有相似之处。不可否认的是，每个人都曾经自己写过几次快速排序算法，但你自己写的版本一写就对的可能性又有多少呢？与之相似，大量的设计问题都与旧有问题相关。因此说，为了解决这些问题，你最好是选取那些现已存在的设计方案，而不是自己去独创一套。

     设计模式通过提供多种设计方案而带来启发性的价值  一个熟悉常见设计模式的设计者能很轻松地找出一些模式来，并且问“选用哪一种设计模式才适合我这里的设计问题？”从一组熟悉的设计方案中寻找，肯定比自己从头开始创造一个设计方案来得容易。对于读者来说，与理解完全定制的代码相比，他们也会更容易理解那些采用了自己熟悉的设计模式的代码。

     设计模式通过把设计对话提升到一个更高的层次上来简化交流  除了在管理复杂度方面的益处之外，设计模式还能够让设计者在更高一层的粒度上进行思考与讨论，从而加速设计交流过程。如果你说“我拿不准在这里是用Creator（创建者）还是Factory Method，”你其实已经言简意赅地传递了非常多的设计决策——如果你和你的听众都熟悉这些模式的话。设想一下，如果你还要深入细节地去解释Creator模式和Factory Method模式的代码细节，然后再去对这两者做出比较，那该会有多费时！

     如果你还对设计模式不熟悉，那么表5-1总结出一些常见设计模式，希望能引起你的兴趣。

     如果你此前没接触过设计模式，那么对表5-1内容的反映可能是“当然，我已经了解其中的多数想法了”。这一反应也是设计模式之所以有价值的很大理由。大多数经验丰富的程序员对模式都很熟悉，给这些模式加上容易辨认的名字，是为了能够更高效、更有效地开展交流。

     应用模式的一个潜在的陷阱是强迫让代码适用于某个模式。有时候，对代码进行一些微小的更改以便符合某个广为人知的模式，会使这段代码更容易理解。但是，如果一段代码做出巨大改动，迫使它去符合某个标准模式，有时反而会把问题复杂化。

     应用模式的另一个潜在陷阱是“为了模式而模式”（feature-it-is）。不要仅仅因为想试用某个模式、不考虑该模式是否合适就去应用它。

     总之，设计模式是一种非常强大的管理复杂度的工具。你可以阅读本章后面所列出的任意一本好书来获取更多更深入的信息。