【译】《学习JavaScript设计模式》（二）

原书连接Learning JavaScript Design Patterns
水平有限不少地方不通顺，错翻漏翻欢迎交流。

模式测试，原生模式&约法三章

记住并非全部的算法啊，最佳实践啊，解决方案啊什么的均可以被称为一个完整的模式的。极可能它就缺了点什么，而社区里的那些家伙就喜欢揪着这小辫子不放，直到它通过千锤百炼出关。即便一个模式已经知足了全部模式标准，还须要通过时不时的合适的测试审查的调教才能成长为一个真正的男人，哦不，模式。

回头看看Alexander说过的，一个模式既是一个过程，也是一个完整的事物。

学习模式设计的过程当中，咱们遇到"原生模式"这玩意儿也不是啥大惊小怪的事。这是个啥？Well，一个还没经过模式测试毕业考试的模式一般就叫原生模式。原生模式的主人把它造出来以后拿到社区里让你们一块儿玩儿，可是因为年纪过小了，还没被从里到外翻云覆雨地玩。

或者把原生模式生下来的人对这一系列的测试根本没啥兴趣，给脖子上挂个出生证实就让它自生自灭去了。咱们一般把这个出生证实叫作"patlets"。

也不怪他们，给这些模式写个完整的文档确实让人萌生退意。回头看看早期的一些工做，知足下列条件的模式才能成为好的模式：

• 解决了一个特定的问题： 我写了一个模式出来，一岁出头鹅蛋脸眉眼带笑鼻子挺直嘴角上扬唇红齿白，可她只能看啥事都作不了有啥用啊。能作事儿，这是一个好的模式最关键的特征。

• 高手都是会隐藏的： 咱们知道解决问题的技术一般都是从一些出名的基本原理衍生出来的。最好的设计模式一般不直接给出问题的答案，这被人认为是解决困难问题的必要步骤。高手嘛，教的都不是形，而是意。

• 给出的概念必定要是被证明过的： 设计模式要给他们的功能提供专业鉴定书，没有专业鉴定书的都是野路子上不了台面。只有勇士和走投无路的人才敢用那些没来历的野生模式。

• 必须阐释清楚代码关系： 有些状况下，模式只是解释了一些模块。不少已经成型的模式可能也只是吊样，可是官方定义的模式必须阐释更底层的系统关系结构并解释清楚代码之间的关系。

看到这儿你或许以为本身不去学习那些不太规则的原生模式没什么关系吧。可不是这样。不少原生模式也是依壁雕凿，固然不是说全部的原生模式都样儿，可是确定有很多很好的原生模式，使用我上面告诉你的方法来自行判断吧。

为了保持模式的可重用性，咱们要约法三章，并将三规则核心价值观时刻牢记心中（别问我这仨有啥区别，核心价值观记住就好了）：

1. 对目标的可用性： 模式是怎么被认为是成功的？

2. 有用性： 为何这个模式被认为是成功的？

3. 适用性： 这是一个由于有普遍适用性因此能成为一个模式的设计吗？若是是，好好写文档吧。重写或者定义模式的时候，记住上面三点是很是重要的。