前言
本文大多数内容都是照搬 [美]Addy Osmani 著《JavaScript设计模式》一书，我单纯是作为读书笔记写的这篇文章（摘记？）。根据网评来说，大部分认为徐涛翻译的不是很好，我个人目前还没看出来有啥问题（没办法，才疏学浅）。
什么是模式？
模式是一种可复用的解决方案，可用于解决软件设计中遇到的常见问题。
再通俗点说，模式是先辈程序员针对开发中遇到的问题提出的大家公认且行之有效的解决方案。
它有三大优点：
- 模式是已经验证的解决方案
- 模式很容易被复用
- 模式富有表达力
前两点就不赘述了，主要说一下第三点：模式富有表达力！原文如下：
看到模式时，通常就表示有一个设置好的结构和表达解决方案的词汇，以帮助我们非常轻松地表达出所实现的大型解决方案。
重要的插曲-共有知识背景下的沟通
从另一个角度说，模式或者说设计模式是重要的沟通语言，就像你学英语一样，说出“hello”时，同样学习，使用这门语言的人能够知道这是“你好”的意思。
这个例子有些特殊，或不具代表性，我真正想表达的是，在具有相同知识背景下，用专用名词或者专业术语去描述一个行为或者方法时，能够使沟通更加快速，且减少认知上的误差。
要知道，人和人的差别比人和猩猩还大！你不知道和你搭档的伙计是半路出家，毫无根底的小白（嗯哼，就是我），还是个浸淫此道多年的老鸟，你二人的知识储备，技术深度，人生阅历不尽相同。
当为了一个任务的实现，你俩要花费半个小时去沟通以及扯皮，甚至要完整复述一遍技术原理，偶尔一次还可以视为工作中的正常沟通，长此以往，双方尽显疲态，尤其是与你合作的人还是个口不择言，双商经常不在线的人，你会倍感心累！
为此！先辈程序员披荆斩棘，立碑作传，数代更新，多方review后提出针对特定情况的特定解决方案，约定了实现结构，讲述了实现原理，表明了方案利弊，探讨了扩展延伸，并将此些相关步骤命名为“设计模式十八式”，其中一招老汉.....咳咳，说错了，不光十八种设计模式，也没有那么三俗的名字。
现在！你和你的搭档沟通时，你与你的伙伴探讨时，再也不用解释为什么这么写，为什么这么写好，为什么要这么做，为什么他那稚嫩不堪坑坑洼洼的代码不堪大用！只需轻启朱唇，低声轻语：“这里用的工厂模式”。
举座皆惊，纳头便拜！纷纷跪倒在你的石榴裙下，高呼：“你是我永远都得不到爸爸！”。
希望你阅读到这里时，你已明白，模式或者说设计模式不仅存在于代码实现层，方案解决层，还存在了最最最重要一层——沟通！
因为跟傻子讲道理，特别的傻。
模式非万能
模式无法解决所有设计问题，模式的作用仅仅是为我们提供一个解决问题的方案。
模式的其他一些优点
- 复用模式，有助于防止开发过程中，小问题引发的大问题。也就是说，在已验证的模式基础上编写代码时，可以在结构上少花时间，从而有更多时间专注于整体解决方案的质量。
- 模式提供通用的解决方案，不局限于编程语言。
- 模式添加到开发人员的词汇中，会使沟通更加快速。
- .....懒得写了
反模式
如果我们认为模式代表最佳实践，那么反模式就代表我们已经学到的教训。
反模式的两个概念：
- 描述一个针对某个特定问题的不良解决方案，该方案会导致糟糕的情况发生；
- 描述如何摆脱第一条描述的糟糕情况以及如何创造好的解决方案；
创建应用程序时，一个项目的生命周期就会以此为起点；一旦完成了初始版本，就需要进行维护。最终方案（如果不明白，可以狭义的理解为代码）的质量好坏取决于技能水平和团队投入的时间。这里的好坏是在上下文中（代码、业务逻辑、因其他因素的实现妥协，如时间，硬件，开发成本等）考虑的，如果一个“完美的”设计应用于错误的上下文中，那么它就可能是一种反模式。
应用程序在进入生产环境并即将进入维护模式时会面临更大的挑战。之前没有研究过该应用程序（未参与前期开发）的开发人员，在这样的系统上工作，可能会将不良的设计，意外地引入到项目中。
如果将不良实践创建为反模式，则能让开发人员有办法提前识别这些反模式，这样就可以避免常见错误的发生，它与下面这个方法类似：设计模式为我们提供了识别有用途，通用技术的方法。总的来说，反模式是一种值得记录的不良设计。
概括来说：反模式就是告诉你，不要这么做，因为会导致某些问题发生，并且告诉你应该如何去做。
JavaScript中反模式示列如下：
- 在全局上下文中定义大量的变量污染全局命名空间
- 修改Object类的原型
- 等等。。
一旦能够辨别这种反模式，我们将能够重构代码来防止他们出现，这样我们解决方案的总体质量就能够立即得到改善。
总结
设计模式要学，要学好，学透。不然你就是听了搭档说了一句“工厂模式”，跪下叫爸爸的选手！
“Royal power has no eternity，my son.”
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
