javascript设计模式.pdfVIP

【Javascript 设计模式 1】-单例模式 《parctical common lisp》的作者曾说，如果你需要一种模式，那一定是哪里 出了问题。他所说的问题是指因为语言的天生缺陷，不得不去寻求和总结一种通 用的解决方案。 不管是弱类型或强类型，静态或动态语言，命令式或说明式语言、每种语言都有 天生的优缺点。一个牙买加运动员， 在短跑甚至拳击方面有一些优势，在练瑜 伽上就欠缺一些。 术士和暗影牧师很容易成为一个出色的辅助，而一个背着梅肯满地图飞的敌法就 会略显尴尬。 换到程序中, 静态语言里可能需要花很多功夫来实现装饰者，而 js 由于能随时往对象上面扔方法，以至于装饰者模式在 js 里成了鸡肋。 讲 javascript 设计模式的书还比较少. Pro javaScript Design Patterns.是比 较经典的一本，但是它里面的例子举得比较啰嗦，所以结合我在工作中写过的代 码，把我的理解总结一下。如果我的理解出现了偏差，请不吝指正。 一 单例模式 单例模式的定义是产生一个类的唯一实例，但 js 本身是一种 “无类”语言。很 多讲 js 设计模式的文章把{}当成一个单例来使用也勉强说得通。因为 js 生成对 象的方式有很多种，我们来看下另一种更有意义的单例。 有这样一个常见的需求，点击某个按钮的时候需要在页面弹出一个遮罩层。比如 点击登录的时候. 这个生成灰色背景遮罩层的代码是很好写的. 问题是, 这个遮罩层是全局唯一的, 那么每次调用 createMask 都会创建一个新 的 div, 虽然可以在隐藏遮罩层的把它 remove 掉. 但显然这样做不合理. 再看下第二种方案, 在页面的一开始就创建好这个 div. 然后用一个变量引用 它. 这样确实在页面只会创建一个遮罩层 div, 但是另外一个问题随之而来, 也许 我们永远都不需要这个遮罩层, 那又浪费掉一个 div, 对 dom 节点的任何操作都 应该非常吝啬. 如果可以借助一个变量. 来判断是否已经创建过 div 呢? 看起来不错, 到这里的确完成了一个产生单列对象的函数. 我们再仔细看这段 代码有什么不妥. 首先这个函数是存在一定副作用的, 函数体内改变了外界变量mask 的引用, 在 多人协作的项目中, createMask 是个不安全的函数. 另一方面, mask 这个全局 变量并不是非需不可. 再来改进一下. 用了个简单的闭包把变量mask 包起来, 至少对于createMask 函数来讲, 它是封 闭的. 可能看到这里, 会觉得单例模式也太简单了. 的确一些设计模式都是非常简单 的, 即使从没关注过设计模式的概念, 在平时的代码中也不知不觉用到了一些 设计模式. 就像多年前我明白老汉推车是什么回事的时候也想过尼玛原来这就 是老汉推车. GOF 里的 23 种设计模式, 也是在软件开发中早就存在并反复使用的模式. 如果 程序员没有明确意识到他使用过某些模式, 那么下次他也许会错过更合适的设 计 (这段话来自《松本行弘的程序世界》). 再回来正题, 前面那个单例还是有缺点. 它只能用于创建遮罩层. 假如我又需 要写一个函数, 用来创建一个唯一的 xhr 对象呢? 能不能找到一个通用的 singleton 包装器. js 中函数是第一型, 意味着函数也可以当参数传递. 看看最终的代码. 用一个变量来保存第一次的返回值, 如果它已经被赋值过, 那么在以后的调用 中优先返回该变量. 而真正创建遮罩层的代码是通过回调函数的方式传人到 singleton 包装器中的. 这种方式其实叫桥接模式. 关于桥接模式, 放在后面 一点点来说. 然而 singleton 函数也不是完美的, 它始终还是需要一个变量 result 来寄存 div 的引用. 遗憾的是 js 的函数式特性还不足以完全的消除声明和语句. 【Javascript 设计模式 2】-简单工厂模式 简单工厂模式是由一个方法来决定到底要创建哪个类的实例, 而这些实例经常 都拥有相同的接口. 这种模式主要用在所实例化的类型在编译期并不能确定， 而是在执行期决定的情况。 说的通俗点，就像公司茶水间的饮料机，要咖啡还 是牛奶取决于你按哪个按钮。 简单工厂模式在创建 ajax 对象的时候也非常有用. 之前我写了一个处理 ajax 异步嵌套的库，地址在 /AlloyTeam/DanceRequest 这个库里提供了几种 ajax 请求的方式，包括 xhr 对象的 get, post, 也包括跨 域用的 jsonp 和 i