JavaScript 编写设计模式

编写设计模式

虽然本书的目标，针对的是新的设计模式，但对设计模式是怎样编写的有一个根本的理解后，会让我们受益匪浅。对于初学者来说，对于为什么需要一个模式背后的推理，我们可以得到更深的理解。我们同时也会学习到当我们在重视我们自己的需求的时候，如何区分一种模式（或原模式）。

要编写好的模式，是一种极具挑战性的任务。模式不仅仅需要对终端用户提供数量可观的材料，还要能够说明为什么需要这种模式。

在读过前续章节-什么是模式以后，我们可能会认为足够帮助我们去辨别我们在非标准条件下看到的模式。事实上这并非完全正确。这并不总是很清楚，如果我们正在寻找的一段代码，出现像它一样符合的一组模式，或只是偶然发生。

当我们在寻找认为可能使用某种设计模式的代码的时候，应该考虑写下的代码的一些方面，我们相信属于一个特定的现有格局或一组模式。

在很多模式分析的案例中，我们会发现，正巧看到了那些具有良好的原则和设计实践，而这些可能突然引起对模式的覆盖规则。记住-既不相互作用，也没有定义规则的解决方案模式。、

如果敢于尝试编写自己的设计模式的道路，我推荐从其他那些已经过来之人学习，学习他们好的方面。花时间从大量不同的设计模式描述中吸取信息，并找到对你有意义的。

探索结构和语义-可以通过检查交互和你感兴趣的模式的上下文，因此你可以标示出运用有用的配置，将模式组织在一起的原则。 

一旦我们暴露了自己丰富的模式文献资料，我们不妨使用现有的格式，开始写我们的模式，并看看我们是否能集思广益，打开新思路，对它进行改进或把我们的想法进行整合。 

一个开发者的例子，该例子的作者是近几年的Christian Heilmann，他在对已存在的模式的基础上做了一些基本的改变，以此创建了暴露模块模式（该模式在本书后续部分会讲到）。 

对于那些对创建新设计模式的人，我对他们有如下的建议：

• 模式是否实用？: 确保这个模式能够对一些常见的问题有明确的解决方案，而不是临时的解决方案。
• 保持最佳实践: 我们的设计需要以最佳实践中所获得的理解作为基础。
• 设计模式对用户来说应该是清晰的: 设计模式必须对任何形式的用户体验都是清晰的。 因为设计模式主要服务于开发者们，所以不能强迫他们去改变原来的行为，那样开发者们才会去使用这个模式。
• 独创力不是设计模式的关键： 当我们在设计一个模式的时候，我们既不需要是发明者，也不需要去担心是否是其他模式的子集。如果某个想法有很强的实用性，那么这就是一个创造新模式的机会。
• 需要有几个有说服力的例子： 一个好的设计模式需要有一个有说服力的例子来展示这个模式是成功的。为了广泛使用这个设计模式，这些例子需要展示良好的设计原则。

在创造一个新的设计模式的时候，在通用性，特殊性和可用性之间有一个微妙的平衡点。如果新的模式覆盖了应用中最多的可能情况，那么这个模式应该是良好的。我希望通过这段简介能够对下个章节内容的学习有所帮助。