原书链接Learning JavaScript Design Patterns
水平有限很多地方不通顺，错翻漏翻欢迎交流。
模式测试，原生模式&约法三章
记住并不是所有的算法啊，最佳实践啊，解决方案啊什么的都可以被称为一个完整的模式的。很可能它就缺了点什么，而社区里的那些家伙就喜欢揪着这小辫子不放，直到它经过千锤百炼出关。即使一个模式已经满足了所有模式标准，还需要经过时不时的合适的测试审查的调教才能成长为一个真正的男人，哦不，模式。
回头看看Alexander说过的，一个模式既是一个过程，也是一个完整的事物。
学习模式设计的过程中，我们遇到”原生模式”这玩意儿也不是啥大惊小怪的事。这是个啥？Well，一个还没通过模式测试毕业考试的模式通常就叫原生模式。原生模式的主人把它造出来之后拿到社区里让大家一起玩儿，但是由于年纪太小了，还没被从里到外翻云覆雨地玩。
或者把原生模式生下来的人对这一系列的测试根本没啥兴趣，给脖子上挂个出生证明就让它自生自灭去了。我们通常把这个出生证明叫做”patlets”。
也不怪他们，给这些模式写个完整的文档确实让人萌生退意。回头看看早期的一些工作，满足下列条件的模式才能成为好的模式：
解决了一个特定的问题： 我写了一个模式出来，一岁出头鹅蛋脸眉眼带笑鼻子挺直嘴角上扬唇红齿白，可她只能看啥事都做不了有啥用啊。能做事儿，这是一个好的模式最关键的特征。
高手都是会隐藏的： 我们知道解决问题的技术通常都是从一些出名的基本原理衍生出来的。最好的设计模式通常不直接给出问题的答案，这被人认为是解决困难问题的必要步骤。高手嘛，教的都不是形，而是意。
给出的概念一定要是被证实过的： 设计模式要给他们的功能提供专业鉴定书，没有专业鉴定书的都是野路子上不了台面。只有勇士和走投无路的人才敢用那些没来历的野生模式。
必须阐释清楚代码关系： 有些情况下，模式只是解释了一些模块。很多已经成型的模式可能也只是吊样，但是官方定义的模式必须阐释更底层的系统关系结构并解释清楚代码之间的关系。
看到这儿你或许觉得自己不去学习那些不太规则的原生模式没什么关系吧。可不是这样。很多原生模式也是依壁雕凿，当然不是说所有的原生模式都样儿，但是肯定有不少很好的原生模式，使用我上面告诉你的方法来自行判断吧。
为了保持模式的可重用性，我们要约法三章，并将三规则核心价值观时刻牢记心中（别问我这仨有啥区别，核心价值观记住就行了）：
对目标的可用性： 模式是怎么被认为是成功的？
有用性： 为什么这个模式被认为是成功的？
适用性： 这是一个因为有广泛适用性所以能成为一个模式的设计吗？如果是，好好写文档吧。重写或者定义模式的时候，记住上面三点是非常重要的。
