设计模式的结构

你可能会对设计模式的作者如何接近勾勒出概念轮廓，实施和新模式的目的。模式是最初提出的一种在两者之间建立关系的规则：

上下文环境
在这种环境下产生的系统的力量
一类配置，考虑到允许这种力量在自己的上下文环境中解决这一点，现在让我们对一种设计模式的组件元素，一探究竟。一种设计模式应该具有：
模式名称和相应的描述
上下文概述-在设计模式中的上下文对响应用户需求是很有效的。
问题声明-一类问题的声明，能让我们理解模式的意图。
解决方案-在可理解的列表和看法上，对用户的问题如何被解决的一种描述。
设计-模式设计，特别是与之交互的用户行为的描述。
实现-对模式如何被实现的一种指引
例证-在模式中的一种类的虚拟化表示
例子-模式实现的一种最下的形式
共同条件-可能会有其他的什么模式会被用到，以对被描述的模式进行支持？
关系-与该模式相似的模式有哪些？是最相似的吗？
已知的使用-模式没有被正常使用？如果是，在哪，怎样做到的？
讨论-有激动人心的获利模式想法的团队或者是作者

在一个组织或团队中，当在同一页面上创建和维护的解决方案时，对所有涉及到的开发者来说，设计模式能帮上大忙。如果考虑到你自己的工作模式，记住，虽然他们可能在制定计划和编写阶段，有一个较大的初期成本投入，但从投资方返回的值是值得的。然而，新的模式工作前，务必深入研究，你会发现它比起重新开始，更有利于使用或建立比现有的行之有效的模式之上。