对付任何还不熟悉设计模式的人来说，在对这个规模举办简短的纵览之后，大概会留下这样的印象：设计模式是一个市场营销大骗局，它不外是一些简朴的编程技能，可能不外是计较机科学家的玩物。尽量这些印象都有那么一点原理，然而设计模式简直是职业C++措施员东西箱中不行或缺的组件。
设计模式是一个被重复谈论的架构主题。它为特定上下文中的常见设计问题提供了办理方案，并描写了这种办理方案的功效。设计模式不只仅是对技能的简朴描写，它照旧从现有的乐成实践一点一滴搜集起来的设计伶俐的具名封装，并以窬交换和复用的方法编写而成。模式关乎措施员之间的顺畅交换。
从实践的角度来看，设计模式具有两个重要的属性。首先，它们描写了颠末验证的、乐成的设计技能，这些技能可以按上下文相关的方法举办定制，以便满意新的设计场所的要求。其次，而且大概更重要的是，在提及某个特定的应用时，不只包罗其顶用到的技能，还包罗应用该模式的动因以及应用后所到达的结果。
这类事物并不是什么新对象。思量一个来自算律例模的类比。思量如下声明：“有一个未排序的序列，必需要举办许多次搜索。因此，但愿对其举办快速排序，而且利用二分查找来执行每一个查找。”可以或许利用术语“快速排序”和“二分查找”，这种代价是不行估计的，不单在设计方面如此，在就该设计与受过教诲的同事举办交换时也如此。当我说“快速排序”时，我的同事知道我正在排序的序列具有随机存取布局，而且它的排序时间巨大度的O(nlog2n)，同时该序列中的元素可以回收雷同小于操纵符举办较量。当我说“二分查找”时，我的同事知道序列已经被排序过了，定位感乐趣的元素所执行的较量操纵的时间巨大度为O(log2n)，而且存在一个适当的操纵来对序列中的元素举办较量。尺度算法所具有的共享的常识以及尺度词汇表，不单答允高效地记录文档，并且答允对设计方案举办有效的评议。好比说，假如我打算对一个单向链接表布局来执行这个查找和排序进程，我的同事立即会自鸣自得地哈哈大笑，并指出在这种环境下我不能利用快速排序而且大概不但愿利用二分查找。
在设计模式呈现之前，在劈面向工具设计的文档化、交换以及高效地评议方面，这些利益都不具备。我们被迫低程度地描写我们的设计，这种方法低效且不足准确。这并不是说用于巨大面向工具设计的技能尚不存在，而是这些技能尚未以一个共享的、通用术语的方法为整个编程社群所用。设计模式办理了这个问题，我们此刻可以像描写算法设计一样高效、毫无歧义地描写面向工具设计。
举个例子，当我们看到Bridge模式被应用到某项设计中时，我们知道在一个简朴的机制层面，抽象数据范例实现被疏散成一个接口类和一个实现类。另外，我们知道这样做的原因是为了将接口从实现强有力地疏散出来，这样，对实现的改变将不会影响到利用接口的用户。我们还知道这种疏散会带来运行期开销，知道应该奈何对抽象数据范例的源代码举办机关，还知道很多其它细节。模式的名字是关于某项技能的诸多信息和履历的高效且无歧义的“句柄”，在设计和文档中小心并正确地利用模式和模式术语，可以使代码和设计越发明晰。
那些严谨的模式专家有时以某种文献的形式来描写模式，这种描写遵循某种正式的布局。尚有几种常见的变体也在利用，但不管哪种描写方法，均包括下面4个必不行少的部门：
首先，设计模式必需具有一个毫无歧义的名字。譬喻，术语“包装器(Wrapper)“对付设计模式定名来说就没有什么意义，因为它早已被遍及利用而且具有很多差异的寄义。利用“Wrapper”这样的术语来定名某种设计模式只会带来夹杂和误解。实际做法是：以前在"Wrapper"名下的设计技能指派为"Bridge" "Strategy" "Facade" "Object Adapter"以及其它一些模式名字。利用准确的模式名字比利用不那么准确的名字具有“明明”的优势，就像术语“二分查找”比“查找”更准确一样。
其次，模式描写必需界说该模式所能办理的问题。这种描写可以相对宽泛，也可以相对狭窄。
再次，模式描写要记述该问题的办理方案。按照告诉的问题，该办理方案可以相对高级，也可以相对初级，但无论如何，它应该具有足够的通用性，以便可以按照问题大概呈现的差异上下文举办定制。
最后，模式描写要记述将该模式应用于某个上下文的效果。在应用该模式后，该上下文是如何产生改变的？不管是变好，照旧变坏。
#p#分页标题#e#
拥有模式的常识可以使一名糟糕的设计师摇身一酿成为一名优秀的设计师吗？呃，是给出另一个类比的时候了，设想你被迫进修某一门让人疾苦的数学课，它的期末测验内容是证明某个规模中的很多定理。假如才气从这门课中死里逃生呢？虽然，最显而易见的方法是成为一个天才。它从最初的道理开始，进而研究整个数学分支的基本常识，最终证明那些定理。一个更为实际的途径是，你紧记并消化该数学规模中的大量定理，并利用它所具备的任何天赋的数学本领、灵感以及好运去选择适当的帮助定理，然后以某种逻辑“胶水”将它们粘合在一起，从而最终证明新的定理。是的，甚至对付那些“传送中的天才”来说，这种方法都是很有优势的，因为基于现成的定理来证明会更高效，同“伧夫俗人”交换起来也更容易。虽然，熟悉帮助定理并不能担保一个可怜的学数学的学生通过测验，但这类常识至少可以使其可以或许领略别人给出的证明。
同样的原理，从最初的道理进而到巨大的面向工具设计也是颇为无趣的，并且与他人交换最终设计也很坚苦。组合利用各类设计模式来生成面向工具设计，雷同于在数学中利用帮助定理来证明一个新的定理。设计模式经常被描写为“微架构(Micro-architecture)“，它们可以与其它模式举办组合从而生成一个新的架构。虽然，选择适当的模式并有效地对其举办组合，也是需要设计方面的专家履历和天资天禀的。不外，一旦设计完成后，甚至你的司理都可以或许领略完整的设计方案，只要他具备一些必须的模式方面的常识即可。
