### 1、策略模式的定义 何为策略？比如我们要去某个地方旅游，可以根据具体的实际情况来选择出行的线路。 - 如果没有时间但是不在乎钱，可以选择坐飞机。 - 如果没有钱，可以选择坐大巴或者火车。 - 如果再穷一点，可以选择骑自行车。 在程序设计中，我们也常常遇到类似的情况，要实现某一个功能有多种方案可以选择。比如一个压缩文件的程序，既可以选择zip算法，也可以选择gzip算法。 **定义：策略模式定义一系列的算法，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算饭的客户.** 策略模式有着广泛的应用。本节我们就以年终奖的计算为例进行介绍。 ### 2、年终奖实例 很多公司的年终奖是根据员工的工资基数和年底绩效情况来发放的。例如，绩效为S的人年终奖有4倍工资，绩效为A的人年终奖有3倍工资，而绩效为B的人年终奖是2倍工资。假设财务部要求我们提供一段代码，来方便他们计算员工的年终奖。 **1. 最初的代码实现** 我们可以编写一个名为calculateBonus的函数来计算每个人的奖金数额。很显然，calculateBonus函数要正确工作，就需要接收两个参数：员工的工资数额和他的绩效考核等级。代码如下： ~~~ var calculateBonus = function( performanceLevel, salary ){ if ( performanceLevel === 'S' ){ return salary * 4; } if ( performanceLevel === 'A' ){ return salary * 3; } if ( performanceLevel === 'B' ){ return salary * 2; } }; calculateBonus( 'B', 20000 ); // 输出：40000 calculateBonus( 'S', 6000 ); // 输出：24000 ~~~ 可以发现，这段代码十分简单，但是存在着显而易见的缺点。 `calculateBonus`函数比较庞大，包含了很多`if-else`语句，这些语句需要覆盖所有的逻辑分支。 `calculateBonus`函数缺乏弹性，如果增加了一种新的绩效等级C，或者想把绩效S的奖金系数改为5，那我们必须深入`calculateBonus`函数的内部实现，这是违反开放-封闭原则的。 算法的复用性差，如果在程序的其他地方需要重用这些计算奖金的算法呢？我们的选择只有复制和粘贴。因此，我们需要重构这段代码。 **2. 使用组合函数重构代码** 一般最容易想到的办法就是使用组合函数来重构它，我们把各种算法封装到一个个的小函数里面，这些小函数有着良好的命名，可以一目了然地知道它对应着哪种算法，它们也可以被复用在程序的其他地方。代码如下： ~~~ var performanceS = function( salary ){ return salary * 4; }; var performanceA = function( salary ){ return salary * 3; }; var performanceB = function( salary ){ return salary * 2; }; var calculateBonus = function( performanceLevel, salary ){ if ( performanceLevel === 'S' ){ return performanceS( salary ); } if ( performanceLevel === 'A' ){ return performanceA( salary ); } if ( performanceLevel === 'B' ){ return performanceB( salary ); } }; calculateBonus( 'A' , 10000 ); // 输出：30000 ~~~ 目前，我们的程序得到了一定的改善，但这种改善非常有限，我们依然没有解决最重要的问题：calculateBonus函数有可能越来越庞大，而且在系统变化的时候缺乏弹性。 **3. 使用策略模式重构代码** 经过思考，我们想到了更好的办法——使用策略模式来重构代码。策略模式指的是定义一系列的算法，把它们一个个封装起来。将不变的部分和变化的部分隔开是每个设计模式的主题，策略模式也不例外，策略模式的目的就是将算法的使用与算法的实现分离开来。 在这个例子里，算法的使用方式是不变的，都是根据某个算法取得计算后的奖金数额。而算法的实现是各异和变化的，每种绩效对应着不同的计算规则。 一个基于策略模式的程序至少由两部分组成。第一个部分是一组策略类，策略类封装了具体的算法，并负责具体的计算过程。 第二个部分是环境类Context，Context接受客户的请求，随后把请求委托给某一个策略类。要做到这点，说明Context中要维持对某个策略对象的引用。 现在用策略模式来重构上面的代码。第一个版本是模仿传统面向对象语言中的实现。我们先把每种绩效的计算规则都封装在对应的策略类里面： ~~~ var performanceS = function(){}; performanceS.prototype.calculate = function( salary ){ return salary * 4; }; var performanceA = function(){}; performanceA.prototype.calculate = function( salary ){ return salary * 3; }; var performanceB = function(){}; performanceB.prototype.calculate = function( salary ){ return salary * 2; }; ~~~ 接下来定义奖金类Bonus： ~~~ var Bonus = function(){ this.salary = null; //原始工资 this.strategy = null; //绩效等级对应的策略对象 }; Bonus.prototype.setSalary = function( salary ){ this.salary = salary; //设置员工的原始工资 }; Bonus.prototype.setStrategy = function( strategy ){ this.strategy = strategy; //设置员工绩效等级对应的策略对象 }; Bonus.prototype.getBonus = function(){ //取得奖金数额 return this.strategy.calculate( this.salary ); //把计算奖金的操作委托给对应的策略对象 }; ~~~ 在完成最终的代码之前，我们再来回顾一下策略模式的思想： **定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。** 这句话如果说得更详细一点，就是：定义一系列的算法，把它们各自封装成策略类，算法被封装在策略类内部的方法里。在客户对Context发起请求的时候，Context总是把请求委托给这些策略对象中间的某一个进行计算。 “并且使它们可以相互替换”，这句话在很大程度上是相对于静态类型语言而言的。因为静态类型语言中有类型检查机制，所以各个策略类需要实现同样的接口。当它们的真正类型被隐藏在接口后面时，它们才能被相互替换。而在JavaScript这种“类型模糊”的语言中没有这种困扰，任何对象都可以被替换使用。因此，JavaScript中的“可以相互替换使用”表现为它们具有相同的目标和意图。 现在我们来完成这个例子中剩下的代码。先创建一个bonus对象，并且给bonus对象设置一些原始的数据，比如员工的原始工资数额。接下来把某个计算奖金的策略对象也传入bonus对象内部保存起来。当调用bonus.getBonus()来计算奖金的时候，bonus对象本身并没有能力进行计算，而是把请求委托给了之前保存好的策略对象： ~~~ var bonus = new Bonus(); bonus.setSalary( 10000 ); bonus.setStrategy( new performanceS() ); //设置策略对象 console.log( bonus.getBonus() ); // 输出：40000 bonus.setStrategy( new performanceA() ); //设置策略对象 console.log( bonus.getBonus() ); // 输出：30000 ~~~ 刚刚我们用策略模式重构了这段计算年终奖的代码，可以看到通过策略模式重构之后，代码变得更加清晰，各个类的职责更加鲜明。但这段代码是基于传统面向对象语言的模仿，下一节我们将了解用JavaScript实现的策略模式。 在5.1节中，我们让strategy对象从各个策略类中创建而来，这是模拟一些传统面向对象语言的实现。实际上在JavaScript语言中，函数也是对象，所以更简单和直接的做法是把strategy直接定义为函数： ~~~ var strategies = { "S": function( salary ){ return salary * 4; }, "A": function( salary ){ return salary * 3; }, "B": function( salary ){ return salary * 2; } }; ~~~ 同样，Context也没有必要必须用Bonus类来表示，我们依然用calculateBonus 函数充当Context来接受用户的请求。经过改造，代码的结构变得更加简洁： ~~~ var strategies = { "S": function( salary ){ return salary * 4; }, "A": function( salary ){ return salary * 3; }, "B": function( salary ){ return salary * 2; } }; var calculateBonus = function( level, salary ){ return strategies[ level ]( salary ); }; console.log( calculateBonus( 'S', 20000 ) ); // 输出： 80000 console.log( calculateBonus( 'A', 10000 ) ); // 输出： 30000 ~~~ ### 3、实例再讲解 一个小例子就能让我们一目了然。 回忆下jquery里的animate方法. ~~~ $( div ).animate( {"left: 200px"}, 1000, 'linear' ); //匀速运动 $( div ).animate( {"left: 200px"}, 1000, 'cubic' ); //三次方的缓动 ~~~ 这2句代码都是让div在1000ms内往右移动200个像素. linear(匀速)和cubic(三次方缓动)就是一种策略模式的封装. 再来一个例子. 很多页面都会有个即时验证的表单. 表单的每个成员都会有一些不同的验证规则.  比如姓名框里面， 需要验证非空，敏感词，字符过长这几种情况。 当然是可以写3个`if else`来解决，不过这样写代码的扩展性和维护性可想而知。如果表单里面的元素多一点，需要校验的情况多一点，加起来写上百个`if else`也不是没有可能。 所以更好的做法是把每种验证规则都用策略模式单独的封装起来。需要哪种验证的时候只需要提供这个策略的名字。就像这样： ~~~ nameInput.addValidata({ notNull: true, dirtyWords: true, maxLength: 30 }) ~~~ 而`notNull`，`maxLength`等方法只需要统一的返回true或者false，来表示是否通过了验证。 ~~~ validataList = { notNull: function( value ){ return value !== ''; }, maxLength: function( value, maxLen ){ return value.length() > maxLen; } } ~~~ 可以看到，各种验证规则很容易被修改和相互替换。如果某天产品经理建议字符过长的限制改成60个字符。那只需要0.5秒完成这次工作。 内容摘自： [JavaScript设计模式与开发实践](http://www.ituring.com.cn/book/1632) [http://www.cnblogs.com/TomXu/archive/2012/03/05/2358552.html](http://www.cnblogs.com/TomXu/archive/2012/03/05/2358552.html) [http://my.oschina.net/fengshuzi/blog/192107](http://my.oschina.net/fengshuzi/blog/192107) [http://www.oschina.net/translate/strategy-design-pattern-in-javascript?print](http://www.oschina.net/translate/strategy-design-pattern-in-javascript?print)

单例模式的定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。 单例模式是一种常用的模式，有一些对象我们往往只需要一个，比如线程池、全局缓存、浏览器的window对象。在js开发中，单例模式的用途同样非常广泛。试想一下，当我们单击登录按钮的时候，页面中会出现一个登录框，而这个浮窗是唯一的，无论单击多少次登录按钮，这个浮窗只会被创建一次。因此这个登录浮窗就适合用单例模式。 ### 1、单例模式的使用场景 在使用一种模式之前，我们最好要知道，这种模式的使用场景。用了这么久的单例模式，竟全然不知！用它具体有哪些好处呢？ - 1.可以用它来划分命名空间(这个就是就是经常用的了) - 2.利用分支技术来封装浏览器之间的差异(这个还真没用过，挺新鲜) - 3.借助单例模式，可以把代码组织的更为一致，方便阅读与维护(这个也用过了) ### 2、最基本的单例模式 最简单的单例其实就是一个对象字面量。它把一批有一定关联的方法和属性组织在一起。 ~~~ var Singleton = { attr1: true , attr2: 10 , method1 : function(){ alert('我是方法1'); }, method2 : function(){ alert('我是方法2'); } }; ~~~ 这个对象可以被修改。你可以添加属性和方法。你也可以用delete运算符删除现有成员。这实际上违背了面向对象设计的一条原则：类可以被扩展，但不应该被修改。如果某些变量需要保护，那么可以将其定义在闭包中。 对象字面量只是创建单例的方法之一。也并非所有的对象字面量都是单例，那些只是用来模仿关联数组或容纳数据的对象字面量显然不是单例。 ### 3、借用闭包创建单例 闭包主要的目地 保护数据 ~~~ // 命名空间 var BHX = {} ; BHX.Singleton = (function(){ // 添加自己的私有成员 var a1 = true ; var a2 = 10 ; var f1 = function(){ alert('f1'); } var f2 = function(){ alert('f2'); } // 把块级作用域里的执行结果赋值给我的单例对象 return { attr1: a1 , attr2: a2 , method1 : function(){ return f1(); }, method2 : function(){ return f2(); } } ; })(); alert(BHX.Singleton.attr1); BHX.Singleton.method1(); ~~~ 这种单例模式又称模块模式，指的是它可以把一批相关的方法和属性组织为模块并起到划分命名空间的作用。 ### 4、单例模式用于划分命名空间 **1、防止全局声明的修改** ~~~ /*using a namespace*/ var BHX = {}; BHX.Singleton = { attr1: true , attr2: 10 , method1 : function(){ alert('我是方法1'); }, method2 : function(){ alert('我是方法2'); } }; BHX.Singleton.attr1; var attr1 = false; ~~~ 这样以来，即使我们在外面声明了相同的变量，也能在一定程度上防止attr1的被修改。 **2、防止其它来源代码的修改** 现在网页上的JavaScript代码往往不止用一个来源，什么库代码、广告代码和徽章代码。为了避免与自己代码的冲突，可以定义一个包含自己所有代码的对象。 ~~~ var XGP = {}; XGP.Common = { //A singleton with common methods used by all objects and modules } XGP.ErrorCodes = { //An object literal used to store data } XGP.PageHandler = { //A singleton with page specific methods and attributes. } ~~~ **3、用作专用代码封装** 在拥有许多网页的网站中，有些代码是所有网页都要用到的，他们通常被存放在独立的文件中；而有些代码则是某个网页专用的，不会被用到其他地方。最好把这两种代码分别包装在自己的单例对象中。 我们经常要用Javascript为表单添加功能。出于平稳退化方面的考虑，通常先创建一个不依赖于Javascript的、使用普通提交机制完成任务的纯HTML网页。 ~~~ XGP.RegPage = { FORM_ID: 'reg-form', OUTPUT_ID: 'reg-result', handleSubmit: function(e){ e.preventDefault(); //stop the normal form submission var data = {}; var inputs = XGP.RegPage.formEl.getElementByTagName('input'); for(var i=0, len=inputs.length; i<len; i++){ data[inputs[i].name] = inputs[i].value; } XGP.RegPage.sendRegistration(data); }, sendRegistration: function(data){ //make an xhr request and call displayResult() when response is recieved ... }, displayResult: function(response){ XGP.RegPage.outputEl.innerHTML = response; }, init: function(){ XGP.RegPage.formEl =$(XGP.RegPage.Form_ID); XGP.RegPage.outputEl = $(XGP.RegPage.OUTPUT_ID); //hijack the form submission addEvent(XGP.RegPage.formEl, 'submit', XGP.RegPage.handleSubmit); } } //invoke initialization method after the page load addLoadEvent(XGP.RegPage.init); ~~~ ### 5、惰性单例 前面所讲的单例模式又一个共同点：单例对象都是在脚本加载时被创建出来。对于资源密集的或配置开销甚大的单例，更合理的做法是将其实例化推迟到需要使用他的时候。 这种技术就是惰性加载(lazy loading)。 实现步骤如下： - 1.将所有代码移到constructor方法中 - 2.全权控制调用时机(正是getInstance所要做的) ~~~ XGP.lazyLoading = (function(){ var uniqInstance; function constructor(){ var attr = false; function method(){ } return { attrp: true, methodp: function(){ } } } return { getInstance: function(){ if(!uniqInstance){ uniqInstance = constructor(); } return uniqInstance; } } })(); ~~~ ### 6、分支技术 分支是一种用来把浏览器间的差异封装在运行期间进行设置的动态方法中的技术。 ~~~ // 分支单例 （判断程序的分支 <浏览器差异的检测>） var Ext = {} ; var def = false ; Ext.More = (function(){ var objA = { // 火狐浏览器 内部的一些配置 attr1:'FF属性1' // 属性1 // 属性2 // 方法1 // 方法2 } ; var objB = { // IE浏览器 内部的一些配置 attr1:'IE属性1' // 属性1 // 属性2 // 方法1 // 方法2 } ; return (def) ?objA:objB; })(); alert(Ext.More.attr1); ~~~ 比如说，如果网站中要频繁使用xhr，每次调用都要再次运行浏览器嗅探代码，这样会严重缺乏效率。更有效的做法是在脚本加载时一次性地确定针对浏览器的代码。这正是分支技术所做的事情。当然，分支技术并不总是更高效的选择，在两个或者多个分支中只有一个分支被用到了，其他分支就占用了内存。 在考虑是否使用分支技术的时候，必须在缩短时间和占用更多内存这一利一弊之间权衡一下。 下面利用分支技术实现XHR： ~~~ var XHR = (function(){ var standard = { createXhrObj: function(){ return new XMLHttpRequest(); } }; var activeXNew = { createXhrObj: function(){ return new ActiveXObject('Msxml2.XMLHTTP'); } }; var activeXOld = { createXhrObj: function(){ return new ActiveXObject('Microsoft.XMLHTTP'); } }; var testObj; try{ testObj = standard.createXhrObj(); return testObj; }catch(e){ try{ testObj = activeXNew.createXhrObj(); return testObj; }catch(e){ try{ testObj = activeXOld.createXhrObj(); return testObj; }catch(e){ throw new Error('No XHR object found in this environment.'); } } } })(); ~~~ ### 7、单例模式的弊端 了解了这么多关于单例的知识，我们再来看看它的弊端。 由于单例模式提供的是一种单点访问，所以它有可能导致模块间的强耦合。因此也就不利于单元测试了。 综上，单例还是留给定义命名空间和实现分支型方法这些用途。 **参考：** [JChenJS设计模式—–单例模式](http://www.cnblogs.com/JChen666/p/3610585.html)

### 1、什么是链式调用 这个很容易理解，例如: ~~~ $(this).setStyle('color', 'red').show(); ~~~ 一般的函数调用和链式调用的区别：调用完方法后，`return this`返回当前调用方法的对象。 ~~~ function Dog(){ this.run= function(){ alert("The dog is running...."); return this;//返回当前对象 Dog }; this.eat= function(){ alert("After running the dog is eatting...."); return this;//返回当前对象 Dog }; this.sleep= function(){ alert("After eatting the dog is running...."); return this;//返回当前对象 Dog }; } //一般的调用方式； /* var dog1 =new Dog(); dog1.run(); dog1.eat(); dog1.sleep();*/ var dog2 = new Dog(); dog2.run().eat().sleep(); ~~~ ### 2、分解链式调用 链式调用其实是两个部分： - 1.**操作对象**(也就是被操作的DOM元素，如上例的$(this)) - 2.**操作方法**(具体要做什么事情，如上例的setStyle和show) 如何实现操作对象与操作方法 创建一般的$函数： ~~~ function $(){ var elements = []; for(var i= 0,len=arguments.length; i<len; i++){ var element = arguments[i]; if(typeof element==='string'){ element = document.getElementById(element); } if(arguments.length==1){ return element; } elements.push(element); } return elements; } ~~~ 但是，如果把这个函数改造为一个构造器，把那些元素作为数组保存在一个实例属性中，并让所有定义在构造器函数的prototype属性所指对象中的方法都返回用以调用方法的那个实例的引用，那么它就具有了链式调用的能力。(说了这么多，就是在每个方法最后`return this;`)， 我首先需要把这个`$`函数改为一个工厂方法，它负责创建支持链式调用的对象。这个函数应该能接受元素数组形式的参数，以便我们能够使用与原来一样的公用接口。这样以来，它就具有了进行链式调用的能力。 改造后如下： ~~~ (function(){ function _$(els){ this.elements = [];//把那些元素作为数组保存在一个实例属性中， for(var i= 0, len=els.length; i<len; i++){ var element = els[i]; if(typeof element==='string'){ element = document.getElementById(element); } this.elements.push(element); } } _$.prototype = { each: function(fn){ for(var i= 0,len=this.elements.length; i<len; i++){ fn.call(this, this.elements[i]); } return this; //在每个方法的最后return this; }, setStyle: function(prop, val){ this.each(function(el){ el.style[prop] = val; }); return this; //在每个方法的最后return this; }, show: function(){ var that = this; this.each(function(el){ that.setStyle('display', 'block'); }); return this; //在每个方法的最后return this; }, addEvent: function(type, fn){ var add = function(el){ if(window.addEventListener){ el.addEventListener(type, fn, false); }else if(window.attachEvent){ el.addEvent('on'+type, fn); } }; this.each(function(el){ add(el); }); return this; //在每个方法的最后return this; } } window.$ = function(){ return new _$(arguments); } })(); ~~~ 在最后return this,这就将调用方法的对象传给调用链上的下一个方法。 ### 3、模拟jquery底层链式编程 ~~~ // 块级作用域 //特点1 程序启动的时候 里面的代码直接执行了 //特点2 内部的成员变量 外部无法去访问 （除了不加var修饰的变量） (function(window , undefined){ // $ 最常用的对象 返回给外界 大型程序开发 一般使用'_'作为私用的对象(规范) function _$(arguments){ //实现代码...这里仅实现ID选择器 // 正则表达式匹配id选择器 var idselector = /#\w+/ ; this.dom ; // 此属性 接受所得到的元素 // 如果匹配成功 则接受dom元素 arguments[0] = '#inp' if(idselector.test(arguments[0])){ this.dom = document.getElementById(arguments[0].substring(1)); } else { throw new Error(' arguments is error !'); } }; // 在Function类上扩展一个可以实现链式编程的方法 Function.prototype.method = function(methodName , fn){ this.prototype[methodName] = fn ; return this ; //链式编程的关键 } // 在_$的原型对象上 加一些公共的方法 _$.prototype = { constructor : _$ , addEvent:function(type,fn){ // 给你的得到的元素 注册事件 if(window.addEventListener){// FF this.dom.addEventListener(type , fn); } else if (window.attachEvent){// IE this.dom.attachEvent('on'+type , fn); } return this ; }, setStyle:function(prop , val){ this.dom.style[prop] = val ; return this ; } }; // window 上先注册一个全局变量 与外界产生关系 window.$ = _$ ; // 写一个准备的方法 _$.onReady = function(fn){ // 1 实例化出来_$对象 真正的注册到window上 window.$ = function(){ return new _$(arguments); }; // 2 执行传入进来的代码 fn(); // 3 实现链式编程 _$.method('addEvent',function(){ // nothing to do }).method('setStyle',function(){ // nothing to do }); }; })(window); // 程序的入口 window传入作用域中 $.onReady(function(){ var inp = $('#inp'); //alert(inp.dom.nodeName); //alert($('#inp')); inp.addEvent('click',function(){ alert('我被点击了!'); }).setStyle('backgroundColor' , 'red'); }); ~~~ ### 4、使用回调函数从支持链式调用的方法获取数据 链式调用很适合于赋值器方法，但对于取值器方法，就不方便了，因为每个方法返回的都是this啊。 不过，变通的方法还是有的，那就是回调函数。 **未使用回调函数时** ~~~ //without callback window.API = window.API || function(){ var name = 'JChen'; this.setName = function(newName){ name = newName; return this; }; this.getName = function(){ return name; }; }; var o = new API(); console.log(o.getName()); console.log(o.setName('Haha').getName()); ~~~ **使用回调函数时** ~~~ //with callback window.API2 = window.API2 || function(){ var name = 'JChen'; this.setName = function(newName){ name = newName; return this; }; this.getName = function(callback){ callback.call(this, name); return this; }; }; var o2 = new API2(); o2.getName(console.log).setName('Hehe').getName(console.log); ~~~ 在使用回调函数时候callback.call(this, name)在一般情况下是没问题的，但是，这个例子偏偏用到了console.log，那么就有问题了。原因是console的this是指向console而不是winodw。 这个问题也很好解决。如下： ~~~ //with callback window.API2 = window.API2 || function(){ var name = 'JChen'; this.setName = function(newName){ name = newName; return this; }; this.getName = function(callback){ callback.call(this, name); return this; }; }; var o2 = new API2(); var log = function(para){ console.log(para); }; o2.getName(log).setName('Hehe').getName(log); ~~~ ### 5、总结 链式调用这种风格有助于简化代码的编写工作，让代码更加简洁、易读，同时也避免多次重复使用一个对象变量。

### 1、继承 在javascript中继承是一个非常复杂的话题，比其他任何面向对象语言的中的继承都复杂得多。在大多数其他面向对象语言中，继承一个类只需要使用一个关键字即可。与它们不同，在javascript中要想达到传承公用成员的目的，需要采取一系列措施。更有甚者，javascript属于使用原型式继承的少数语言之一。利益于这种语言的灵活性，你既可使用标准的基于类的继承，也可使用更微妙一些的原型式继承。 ### 2、为什么需要继承? 一般来说，在设计类的时候，我们希望能减少重复性的代码，并且尽量弱化对象间的耦合。使用继承符合前一个设计原则的需要。借助这种机制，你可以在现有类的基础上进行设计并充分利用它们已经具备的各种方法，而对设计进行修改也更为轻松。假设你需要让几个类都拥有一个按特定方式输出类结构的toString()方法，当然可以用复制加粘贴的办法把定义toString()方法的代码添加到每一个类中，但这样做的话，每当需要改变这个方法的工作方式时，你将不得不在每一个类中重复同样的修改。反之，如果你提供了一个ToStringProvider类，然后让那些类继承这个类，那么toString这个方法只需在一个地方声明即可。 让一个类继承另一个类可能会导致二者产生强耦合，也即一个类的依赖于另一个类的内部实现。我们将讨论一些有助于避免这种问题的技术，其中包括用掺元类为其他类提供方法这种技术。 ### 3、基于类的继承 下面看下面的代码： ~~~ <script type="text/javascript"> function Person(name, age) { this.name = name; this.age = age; } Person.prototype.say = function () { console.log(this.name + " , " + this.age); } function Student(no) { this.no = no; } /** * Student的prototype指向Person的对象 */</span> Student.prototype = new Person(); var stu1 = new Student("0001"); stu1.name = '张三'; stu1.age = '11'; console.log(stu1.no); stu1.say(); </script> ~~~ 输出结果： ~~~ 0001 张三 , 11 ~~~ 可以看到Student成功集成了Person，并且拥有了Person的say方法，核心代码其实就是一句 Student.prototype = new Person();，下面通过图解来说明原理：  将Student.prototype指向new Person() , new Person的`_proto_`又指向Person Prototype；这样完成了整个继承。 但是这种方式存在问题： **问题1：**当父类存在引用类型变量时，造成数据不一致，下面我们给Person添加一个hobbies属性，类型为数组。 ~~~ <script type="text/javascript"> /** * 存在问题 * 1、无法在Student的构造方法中传递参数用于父类的构造方法 * 2、对于引用类型变量，造成数据不一致 */ function Person(name, age) { this.name = name; this.age = age; this.hobbies = [] ; } Person.prototype.say = function () { console.log(this.name + " , " + this.age +" , " +this.hobbies); } function Student(no) { this.no = no; } Student.prototype = new Person(); var stu1 = new Student("0001"); stu1.name = '张三'; stu1.age = '11'; stu1.hobbies.push("soccer"); stu1.say(); var stu2 = new Student("0002"); stu2.name = '李四'; stu2.age = '12'; stu2.hobbies.push("girl"); stu2.say(); </script> ~~~ 输出结果： ~~~ 张三 , 11 , soccer 李四 , 12 , soccer,girl ~~~ 可以看出，李四的hobbies应该只有girl，但是上面的代码让所有对象共享了hobbies属性。 上述的继承方式还存在一个问题： **问题2：**在Student的构造方法中，无法使用new Student(“00001” , “张三” , 12) ；创建对象，并初始化name和age属性，必须stu.name, stu.age进行赋值 为了解决上述问题，对上述代码进行修改： ~~~ <script type="text/javascript"> function Person(name, age) { this.name = name; this.age = age; this.hobbies = []; } Person.prototype.say = function () { console.log(this.name + " , " + this.age +" , " + this.hobbies); } function Student(name, age, no) { /** * 使用call方法，第一个参数为上下文； * 有点类似Java中的super(name,age)的感觉 */ Person.call(this, name, age); this.no = no; } Student.prototype = new Person(); var stu1 = new Student("0001","张三",11); stu1.hobbies.push("soccer"); stu1.say(); var stu2 = new Student("0002","李四",12); stu2.hobbies.push("cangjin"); stu2.hobbies.push("basketball"); stu2.say(); </script> ~~~ 输出： ~~~ 0001 , 张三 , soccer 0002 , 李四 , cangjin,basketball ~~~ 在Student的构造方法中使用了Person.call(this,name,age)感觉就像super(name,age)【call的第一个参数为上下文】；并且成功解决了对引用属性的共享问题，完美解决。 ### 4、基于原型链的继承 ~~~ <script type="text/javascript"> /** * 基于原型链的集成中都是对象 * 存在问题： * 1、对于引用类型变量，造成数据不一致 */ var Person = { name: "人", age: 0, hobbies: [], say: function () { console.log(this.name + " , " + this.age + " , " + this.hobbies); } } ; var Student = clone(Person); Student.no =""; Student.sayHello = function() { console.log(this.name +"hello ") ; } var stu1 = clone(Student); stu1.name = "zhangsan"; stu1.age = 12; stu1.hobbies.push("Java"); stu1.say(); var stu2 = clone(Student); stu2.name = "lisi"; stu2.age = 13; stu2.hobbies.push("Javascript"); stu2.say(); /** * 返回一个prototype执行obj的一个对象 * @param obj * @returns {F} */ function clone(obj) { var F = function () { }; F.prototype = obj; return new F(); } </script> ~~~ 输出： ~~~ zhangsan , 12 , Java lisi , 13 , Java,Javascript ~~~ 可以看出同样存在引用属性不一致的问题，并且整个操作全部基于对象，给人的感觉不是很好，下面通过图解解释下原理：  对象间通过一个clone函数，不断的返回一个新的对象，且prototype执行传入的对象，整个继承过程其实就是`_proto_`不断的指向，形成一个链，所以叫做原型链。 好了，已经介绍完了，js的两种集成的方式，最好使用的还是通过类的继承（上述第一种方案，解决存在问题的）。

在JavaScript 中，并没有对抽象类和接口的支持。JavaScript 本身也是一门弱类型语言。在封装类型方面，JavaScript 没有能力，也没有必要做得更多。对于JavaScript 的设计模式实现来说，不区分类型是一种失色，也可以说是一种解脱。 从设计模式的角度出发，封装在更重要的层面体现为封装变化。 通过封装变化的方式，把系统中稳定不变的部分和容易变化的部分隔离开来，在系统的演变过程中，我们只需要替换那些容易变化的部分，如果这些部分是已经封装好的，替换起来也相对容易。这可以最大程度地保证程序的稳定性和可扩展性。 javascript封装的的基本模式有3种。 ### 1、使用约定优先的原则，将所有的私有变量以_开头 ~~~ <script type="text/javascript"> /** * 使用约定优先的原则，把所有的私有变量都使用_开头 */ var Person = function (no, name, age) { this.setNo(no); this.setName(name); this.setAge(age); } Person.prototype = { constructor: Person, checkNo: function (no) { if (!no.constructor == "string" || no.length != 4) throw new Error("学号必须为4位"); }, setNo: function (no) { this.checkNo(no); this._no = no; }, getNo: function () { return this._no; setName: function (name) { this._name = name; }, getName: function () { return this._name; }, setAge: function (age) { this._age = age; }, getAge: function () { return this._age; }, toString: function () { return "no = " + this._no + " , name = " + this._name + " , age = " + this._age; } }; var p1 = new Person("0001", "小平果", "22"); console.log(p1.toString()); //no = 0001 , name = 小平果 , age = 22 p1.setNo("0003"); console.log(p1.toString()); //no = 0003 , name = 小平果 , age = 22 p1.no = "0004"; p1._no = "0004"; console.log(p1.toString()); //no = 0004 , name =小平果 , age = 22 </script> ~~~ 看完代码，是不是有种被坑的感觉，仅仅把所有的变量以_开头，其实还是可以直接访问的，这能叫封装么，当然了，说了是约定优先嘛. 下划线的这种用法这一个众所周知的命名规范，它表明一个属性仅供对象内部使用，直接访问它或设置它可能会导致意想不到的后果。这有助于防止程序员对它的无意使用，却不能防止对它的有意使用。 这种方式还是不错的，最起码成员变量的getter，setter方法都是prototype中，并非存在对象中，总体来说还是个不错的选择。如果你觉得，这不行，必须严格实现封装，那么看第二种方式。 ### 2、严格实现封装 ~~~ <script type="text/javascript"> /** * 使用这种方式虽然可以严格实现封装，但是带来的问题是get和set方法都不能存储在prototype中，都是存储在对象中的 * 这样无形中就增加了开销 */ var Person = function (no, name, age) { var _no , _name, _age ; var checkNo = function (no) { if (!no.constructor == "string" || no.length != 4) throw new Error("学号必须为4位"); }; this.setNo = function (no) { checkNo(no); _no = no; }; this.getNo = function () { return _no; } this.setName = function (name) { _name = name; } this.getName = function () { return _name; } this.setAge = function (age) { _age = age; } this. getAge = function () { return _age; } this.setNo(no); this.setName(name); this.setAge(age); } Person.prototype = { constructor: Person, toString: function () { return "no = " + this.getNo() + " , name = " + this.getName() + " , age = " + this.getAge(); } } ; var p1 = new Person("0001", "小平果", "22"); console.log(p1.toString()); //no = 0001 , name =小平果 , age = 22 p1.setNo("0003"); console.log(p1.toString()); //no = 0003 , name = 小平果 , age = 22 p1.no = "0004"; console.log(p1.toString()); //no = 0003 , name = 小平果 , age = 22 </script> ~~~ 那么这与我们先前讲过的其他创建对象的模式有什么不同呢，在上面的例子中，我们在创建和引用对象的属性时总要使用this关键字。而在本例中，我们用var声明这些变量。这意味着它们只存在于Person构造器中。checkno函数也是用同样的方式声明的，因此成了一个私用方法。 需要访问这些变量和函数的方法只需要声明在Person中即可。这些方法被称为特权方法，因为它们是公用方法，但却能够访问私用属性和方法。为了在对象外部能访问这些特权函数，它们的前面被加上了关键字this。因为这些方法定义于Person构造器的作用域，所以它们能访问到私用属性。引用这些属性时并没有使用this关键字，因为它们不是公开的。所有取值器和赋值器方法都被改为不加this地直接引用这些属性。 任何不需要直接访问的私用属性的方法都可以像原来那样在Person.prototype中声明。像toString()方法。只有那些需要直接访问私用成员的方法才应该被设计为特权方法。但特权方法太多又会占用过多的内存，因为每个对象实例都包含所有特权方法的新副本。 看上面的代码，去掉了this.属性名，严格的实现了封装，只能通过getter，setter访问成员变量了，但是存在一个问题，所有的方法都存在对象中，增加了内存的开销。 ### 3、以闭包的方式封装 ~~~ <script type="text/javascript"> var Person = (function () { //静态方法（共享方法） var checkNo = function (no) { if (!no.constructor == "string" || no.length != 4) throw new Error("学号必须为4位"); }; //静态变量（共享变量） var times = 0; //return the constructor. return function (no, name, age) { console.log(times++); // 0 ,1 , 2 var no , name , age; //私有变量 this.setNo = function (no) //私有方法 { checkNo(no); this._no = no; }; this.getNo = function () { return this._no; } this.setName = function (name) { this._name = name; } this.getName = function () { return this._name; } this.setAge = function (age) { this._age = age; } this.getAge = function () { return this._age; } this.setNo(no); this.setName(name); this.setAge(age); } })(); Person.prototype = { constructor: Person, toString: function () { return "no = " + this._no + " , name = " + this._name + " , age = " + this._age; } }; var p1 = new Person("0001", "小平果", "22"); var p2 = new Person("0002", "abc", "23"); var p3 = new Person("0003", "aobama", "24"); console.log(p1.toString()); //no = 0001 , name = 小平果 , age = 22 console.log(p2.toString()); //no = 0002 , name = abc , age = 23 console.log(p3.toString()); //no = 0003 , name = aobama , age = 24 </script> ~~~ 上述代码，js引擎加载完后，会直接执行Person = 立即执行函数，然后此函数返回了一个子函数，这个子函数才是new Person所调用的构造函数，又因为子函数中保持了对立即执行函数中checkNo(no) ，times的引用，（很明显的闭包）所以对于checkNo和times，是所有Person对象所共有的，创建3个对象后，times分别为0，1，2 。这种方式的好处是，可以使Person中需要复用的方法和属性做到私有且对象间共享。 这里的私用成员和特权成员仍然被声明在构造器。但那个构造器却从原来的普通函数变成了一个内嵌函数，并且被作为包含它的函数的返回值给变量Person。这就创建了一个闭包，你可以把静态的私用成员声明在里面。位于外层函数声明之后的一对空括号很重要，其作用是代码一载入就立即执行这个函数。这个函数的返回值是另一个函数，它被赋给Person变量，Person因此成了一个构造函数。在实例华Person时，所调用的这个内层函数。外层那个函数只是用于创建一个可以用来存储静态成员的闭包。 在本例中，checkno被设计成为静态方法，原因是为Person的每个实例都生成这个方法的一个新副本毫无道理。此外还有一个静态属性times，其作用在于跟踪Person构造器的总调用次数。

### 1、接口概述 **1。什么是接口？** 接口是提供了一种用以说明一个对象应该具有哪些方法的手段。尽管它可以表明这些方法的语义，但它并不规定这些方法应该如何实现。 **2. 接口之利** - 促进代码的重用。 接口可以告诉程序员一个类实现了哪些方法，从而帮助其使用这个类。 - 有助于稳定不同类之前的通信方式。 - 测试和调式因此也能变得更轻松。 在javascript这种弱类型语言中，类型不匹配错误很难跟踪。使用接口可以让这种错误的查找变午更容易一点，因为此时如果一个对象不像所要求的类型，或者没有实现必要的方法，那么你会得到包含有用信息的明确的错误提示。这样一来，逻辑错误可以被限制在方法自身，而不是在对象构成之中。 - 接口还能让代码变得更稳固. 因为对接口的任何改变在所有实现它的类都必须体现出来。如果接口添加了一个操作，而某个实现它的类并没有相应的添加这个操作，那么你肯定会立即见到一个错误。 **3. 接口之弊** javascript是一种具有极强表现图片的语言，这主要得益于其弱类型的特点。而接口的使用则一定程序上强化了类型的作用。这降低了语言的灵活性。javascript并没有提供对接口的内置支持，而试图模仿其它语言内置的功能总会有一些风险。 js中接口使用的最大问题在于，无法强迫其他程序员遵守你定义的接口。在其它语言中，接口的概念是内置的，如果某人定义了实现一个接口的类，那么编译器会确保该类的确实现了这个接口。而在javascript中则必须用手工的办法保证某个类实现了一个接口。编码规范和辅助类可以提供一些帮助，但无法彻底根除这个问题。如果项目的其他程序员不认真对待接口，那么这些接口的使用是无法得到强制性保证的。除非项目的所有人都同意使用接口并对其进行检查，否则接口的很多价值都无从体现。 ### 2、在javascript中模仿接口 javascript中模仿接口的三种方法：注解描述法、属性检查法、鸭式辨型法。 没有哪种技术是完美的，但三者结合使用基本上可以令人满意。 **1、注释描述法实现接口** 用注释模仿接口是最简单的方法，但效果却是最差的。这种方法模仿其他页面对象语言中的做法，使用了interface和implements关键字，但把它们放在注释中，以免引起语法错误。如下： ~~~ //javascript中定义接口的方式有三种： //1、注解描述的方式 /** * interface Composite{ * function add(obj); * function remove(obj); * function update(obj); } 优点：程序员可以有参考 缺点：缺点一大堆，他只是一个借口的文档范畴，假如不实现 所有的方法，程序照样可以运行，太松散了。对测试和调试难度大 */ // Implement of interface Composite var CompositeImpl =function(){ /*this.add = function(obj){ }; this.remove = function(obj){ }; 这种函数定义的方法，在实例化一个对象的时候，new 一个示例，将产生一个方法，且各个实力的方法还不一样。 所以采用下面的方法： */ CompositeImpl.prototype.add = function(obj){ } CompositeImpl.prototype.remove = function(obj){ } CompositeImpl.prototype.update = function(obj){ } } var c1 = new CompositeImpl(); var c2 = new CompositeImpl() alert(c1.add == c2.add) ~~~ 这种模仿并不是很好。它没有为确保Composite真正实现了正确的方法集而进行检查，也不会抛出错误以告知程序员程序中的问题。说到底它主要还是属于程序文档范畴。在这种做法中，对接口约定的遵守完全依靠自觉。 **2、属性检测法实现接口** 这种方法更严谨一点。所有类都明确地声明自己实现了哪些接口，那些想与这些类打交道的对象可能针对这些声明进行检查。那些接口自身仍然只是注释，但现在你可以通过检查一个属性得知某个类自称实现了什么接口。 ~~~ /** * interface Composite{ * function add(obj); * function remove(obj); * function update(obj); * } * interface FormItem{ * function select(obj); * } */ // CompositeImpl implements interface Composite,FormItem var CompositeImpl =function(){ //显示在类的内部，接收所实现的接口，一般来说，这是一个规范， // 我们项目经理：在内部类定义一个数组，名字要固定 this.interfaceImplments = ['Composite','FormItem']; CompositeImpl.prototype.add = function(obj){ alert("小平果"); } CompositeImpl.prototype.remove = function(obj){ } CompositeImpl.prototype.update = function(obj){ } /*CompositeImpl.prototype.select = function(obj){ }*/ } //定义函数检测，判断当前对象是否实现了所有的接口 function checkCompositeImpl (instance){ if (!isImplments(instance,'Composite','FormItem')) { throw new Error('Object cannot implements all the interface'); }; } //公用的具体检测方法（核心方法）,主要目的就是判断示例对象有没有实现相关的接口； function isImplments(object){ //arguments 对象会的函数的实际对象 for (var i = 1, len = arguments.length; i < len; i++) { //注意这里从1开始，逐个方法判断。 var interfaceName = arguments[i]; //接收实现每一个接口的名字 var interfaceFound = false;//判断此方法到底是实现了还是失败了？规范里定义了interfaceImplments. for (var j = 0;j < object.interfaceImplments.length; j++) { if(object.interfaceImplments[j] == interfaceName){ interfaceFound = true; break; } }; //如果没有实现，则返回false if (!interfaceFound) { return false; }; } return true; } var c1 = new CompositeImpl(); checkCompositeImpl(c1); c1.add(); ~~~ 这个例子中，CompositeImpl 宣称自己实现了Composite接口，其做法是把这两个接口名称加入一个名为implementsInterfaces的数组。类显式声明自己支持什么接口。任何一个要求基于参数属于特定类型的函数都可以对这个属性进行检查，并在所需接口未在声明之列时抛出一个错误。 这种方法有几个优点。它对类所实现的接口提供了文档说明。如果需要的接口不在一个类宣称支持的接口之列，你会看到错误消息。通过利用这些错误，你可以强迫其他程序员声明这些接口。 这种方法的主要缺点在于它并未确保类真正实现了自称实现的接口。你只知道它是否说自己实现了接口。在创建一个类时声明它实现了一个接口，但后来在实现该接口所规定的方法时却漏掉其中的某一个，这种错误很常见。此时所有检查都能通过，但那个方法却不存在，这将在代码中埋下一个隐患。另外显式声明类所支持的接口也需要一些额外的工作。 **3、鸭式辨型法实现接口** 其实，类是否声明自己支持哪些接口并不重要，只要它具有这些接口中的方法就行。鸭式辨型（这个名称来自James Whitomb Riley的名言：“像鸭子一样走路并且嘎嘎叫的就是鸭子”）正是基于这样的认识。它把对象实现的方法集作作为判断它是不是某个类的实例的唯一标准。这种技术在检查一个类是否实现了某个接口时也可大显向身手。这种方法背后的观点很简单：如果对象具有与接口定义的方法同名的所有方法，那么就可以认为它实现了这个接口。你可以用一个辅助函数来确保对象具有所有必需的方法: ~~~ /* 实现接口的第三种方式：鸭式辨型发实现接口，（较为完美的实现方法） 核心思想：一个类实现接口的主要目的：把其中的方法都实现了（检测方法） 完全面向对象 代码实现统一，实现解耦*/ //1、接口类---Class Interface ===>实例化N多个接口 /** *接口类的参数？几个 * 参数1：接口名 * 参数2：接收方法的集合（数组） */ var Interface = function(name , methods){ //判断接口的参数个数 if (arguments.length !=2) { throw new Error('the instance interface constructor arguments should be 2'); }; this.name =name; //this.methods = methods; this.methods = []; for (var i = 0, len = methods.length; i <len; i++) { if (typeof methods[i] !== "string"){ throw new Error('the name of method is wrong'); } this.methods.push(methods[i]); } } //2、准备工作，具体的实现 //(1)实例化接口对象 var CompositeInterface = new Interface('CompositeInterface',['add','delete']); var FormItemInterface = new Interface('FormItemInterface',['update','select']); //(2)具体的实现类 //CompositeImpl implments CompositionIterface FormItemIterface var CompositeImpl = function(){ } //(3)实现接口的方法 implements methods CompositeImpl.prototype.add = function(obj){ alert("add"); } CompositeImpl.prototype.delete = function(obj){ alert("delete"); } CompositeImpl.prototype.update = function(obj){ alert("update"); } /*CompositeImpl.prototype.select = function(obj){ alert("select"); }*/ //3、检验接口里的方法 //如果检测通过，不做任何操作；不通过，则抛出异常。 //这个方法的目的就是 检测方法的 Interface.ensureImplements =function(object){ //如果接受参数长度小于2 ，证明还有任何实现的接口 if (arguments.length < 2) { throw new Error('The Interface has no implement class'); }; //获得接口的实例对象 for (var i = 1, len= arguments.length; i < len; i++) { var instanceInterface =arguments[i]; //判断参数是否为 接口类的类型 if (instanceInterface.constructor !==Interface) { throw new Error('The arguments constructor is not Interface Class'); }; for (var j = 0, len2 =instanceInterface.methods.length ; j <len2; j++ ) { //用一个临时变量 ，接收每个方法的名字（注意为字符串类型） var methodName = instanceInterface.methods[j]; //object[key] 获得方法 if (!object[methodName] || typeof object[methodName] !== 'function') { throw new Error('the method"'+ methodName+'"is not found'); } } } } var c1 =new CompositeImpl(); Interface.ensureImplements(c1,CompositeInterface,FormItemInterface); c1.add(); ~~~ 与另外两种方法不同，这种方法并不借助注释。其各个方面都是可以强制实施的。ensureImplements函数需要至少两个参数。第一个参数是想要检查的对象。其余参数是据以对那个对象进行检查的接口。该函数检查其第一个参数代表的对象是否实现了那些接口所声明的所有方法。如果发现漏掉了任何一个方法，它就会抛出错误，其中包含了所缺少的那个方法和未被正确实现的接口的名称等有用信息。这种检查可以用在代码中任何需要确保某个对象实现了某个接口的地方。在本例中，addForm函数仅当一个表单对象支持所有必要的方法时才会对其执行添加操作。 尽管鸭式辨型可能是上述三种方法中最有用的一种，但它也有一些缺点。这种方法中，类并不声明自己实现了哪些接口，这降低了代码的可重用性，并且也缺乏其他两种方法那样的自我描述性。它需要使用一个辅助类Interface和一个辅助函数ensureImplements。而且，它只关心方法的名称，并不检查其参数的名称、数目或类型。 ### 3、Interface类的使用场合 严格的类型检查并不总是明智的。许多js程序员根本不用接口或它所提供的那种检查，也照样一干多年。接口在运用设计模式实现复杂系统的时候最能体现其价值。它看似降低javascript的灵活性，而实际上，因为使用接口可以降低对象间的耦合程度，所以它提高了代码的灵活性。接口可以让函数变得更灵活，因为你既能向函数传递任何类型的参数，又能保证它只会使用那些具有必要方法的对象。 ### 4、Interface类的用法 判断代码中使用接口是否划算是最重要的一步。对于小型的、不太费事的项目来说，接口的好处也许并不明显，只是徒增其复杂度而已。你需要自行权衡其利弊。如果认为在项目中使用接口利大于弊，那么可以参照如下使用说明： 1、 将Interface类纳入HTML文件。 2、 逐一检查代码中所有以对象为参数的方法。搞清代码正常运转要求的这些对象参数具有哪些方法 3、 为你需要的每一个不同的方法集创建一个Interface对象。 4、 剔除所有针对构造器显式检查。因为我们使用是鸭式辨型，所以对象的类型不再重要。 5、 以Interface.ensureImplements取代原来的构造器检查。 示例 假设你要创建一个类，它可以将一些自动化测试结果转化为适于在网页上查看的格式。该类的构造器以一个TestResult类的实例为参数。它会应客户的请求对这个TestResult对象所封装的数据进行格式化，然后输出。 原始定义： ~~~ var ResultFormatter =function(resultsObject){ if(!(resultsObject instanceof TestResult)){ throw newError("ResultsFormatter:constructor requires an instance of TestResult asan argument.") } this.resultsObject = resultsObject; } ResultFormatter.prototype.renderResults =function(){ var dateOfTest = this.resultsObject.getDate(); var resultsArray =this.resultsObject.getResults(); var resultsContainer =document.createElement('div'); var resultsHeader =document.createElement("h3"); resultsHeader.innerHTML = "TestResults from "+dateOfTest.toUTCString(); resultsContainer.appendChild(resultsHeader); var resultList =document.createElement("ul"); resultsContainer.appendChild(resultList); for(var i=0,len=resultsArray.length;i<len;i++){ var listItem=document.createElement('li'); listItem.innerHTML =resultsArray[i]; resultList.appendChild(listItem); } return resultsContainer; } ~~~ 该类的构造器会对参数进行检查，以确保其的确为TestResult类的实例。如果参数达不到要示，构造器将抛出一个错误。有了这样的保证，在编写renderResults方法时，你就可以认定有getDate和getResults这两个方法可供使用。实际上这并不能保证所需要的方法得到了实现。TestResult类可能会被修改，致使其不再拥有getDate()方法。在此情况下，构造器中的检查仍能通过，但renderResults方法却会失灵。 此外，构造器的这个检查施加了一些不必要的限制。它不允许使用其他类的实例作为参数，哪怕它们原本可以如愿发挥作用。例如，有一个名为WeatherData在也拥有getDate和getResults这两个方法。它本来可以被ResultFormatter类用得好好的。但是那个显式类型检查会阻止使用WeatherData类的任何实例。 问题解决办法是删除那个使用instanceOf的检查，并用接口代替它。首先，我们需要创建这个接口： ~~~ //ResultSetInterface. var ResultSet =new Interface(“ResultSet”,[‘getDate’,’getResults’]); ~~~ 上面的这行代码创建了一个Interface对象的新实例。第一个参数是接口的名称，第二个参数是一个字符串数组，其中的每个字符串都是一个必需的方法名称。有了这个接口之后，就可以用接口检查替代instanceOf检查了 ~~~ var ResultFormatter = function(resultsObject){ Interface.ensureImplements(resultsObject,ResultSet); this.resultsObject = resultsObject; } ResultFormatter.prototype.renderResults= function(){ … } ~~~ renderResults方法保持不变。而构造器则被改为使用ensureImplements方法而不是instanceof运算符。现在构造器可以接受WeatherData或其他任何实现所需要方法的类的实例。我们只修改了几行ResultFormatter类代码，就让那个检查变得更准确，而且更宽容。 ### 5、依赖于接口的设计模式 - 工厂模式 - 组合模式 - 装饰模式 - 命令模式

多态的实际含义是：同一操作作用于不同的对象上面，可以产生不同的解释和不同的执行结果。换句话说，给不同的对象发送同一个消息的时候，这些对象会根据这个消息分别给出不同的反馈。 从字面上来理解多态不太容易，下面我们来举例说明一下。 主人家里养了两只动物，分别是一只鸭和一只鸡，当主人向它们发出“叫”的命令时，鸭会“嘎嘎嘎”地叫，而鸡会“咯咯咯”地叫。这两只动物都会以自己的方式来发出叫声。它们同样“都是动物，并且可以发出叫声”，但根据主人的指令，它们会各自发出不同的叫声。 其实，其中就蕴含了多态的思想。下面我们通过代码进行具体的介绍。 ### 1. 一段“多态”的JavaScript代码 我们把上面的故事用JavaScript代码实现如下： ~~~ var makeSound = function( animal ){ if ( animal instanceof Duck ){ console.log( '嘎嘎嘎' ); }else if ( animal instanceof Chicken ){ console.log( '咯咯咯' ); } }; var Duck = function(){}; var Chicken = function(){}; makeSound( new Duck() ); //嘎嘎嘎 makeSound( new Chicken() ); //咯咯咯 ~~~ 这段代码确实体现了“多态性”，当我们分别向鸭和鸡发出“叫唤”的消息时，它们根据此消息作出了各自不同的反应。但这样的“多态性”是无法令人满意的，如果后来又增加了一只动物，比如狗，显然狗的叫声是“汪汪汪”，此时我们必须得改动makeSound函数，才能让狗也发出叫声。修改代码总是危险的，修改的地方越多，程序出错的可能性就越大，而且当动物的种类越来越多时，makeSound有可能变成一个巨大的函数。 多态背后的思想是将“做什么”和“谁去做以及怎样去做”分离开来，也就是将“不变的事物”与 “可能改变的事物”分离开来。在这个故事中，动物都会叫，这是不变的，但是不同类型的动物具体怎么叫是可变的。把不变的部分隔离出来，把可变的部分封装起来，这给予了我们扩展程序的能力，程序看起来是可生长的，也是符合开放-封闭原则的，相对于修改代码来说，仅仅增加代码就能完成同样的功能，这显然优雅和安全得多。 ### 2. 对象的多态性 下面是改写后的代码，首先我们把不变的部分隔离出来，那就是所有的动物都会发出叫声： ~~~ var makeSound = function( animal ){ animal.sound(); }; ~~~ 然后把可变的部分各自封装起来，我们刚才谈到的多态性实际上指的是对象的多态性： ~~~ var Duck = function(){} Duck.prototype.sound = function(){ console.log( '嘎嘎嘎' ); }; var Chicken = function(){} Chicken.prototype.sound = function(){ console.log( '咯咯咯' ); }; makeSound( new Duck() ); //嘎嘎嘎 makeSound( new Chicken() ); //咯咯咯 ~~~ 现在我们向鸭和鸡都发出“叫唤”的消息，它们接到消息后分别作出了不同的反应。如果有一天动物世界里又增加了一只狗，这时候只要简单地追加一些代码就可以了，而不用改动以前的makeSound函数，如下所示： ~~~ var Dog = function(){} Dog.prototype.sound = function(){ console.log( '汪汪汪' ); }; makeSound( new Dog() ); //汪汪汪 ~~~ ### 3. 类型检查和多态 类型检查是在表现出对象多态性之前的一个绕不开的话题，但JavaScript是一门不必进行类型检查的动态类型语言，为了真正了解多态的目的，我们需要转一个弯，从一门静态类型语言说起。 静态类型语言在编译时会进行类型匹配检查。以Java为例，由于在代码编译时要进行严格的类型检查，所以不能给变量赋予不同类型的值，这种类型检查有时候会让代码显得僵硬，代码如下： ~~~ String str; str = abc; //没有问题 str = 2; //报错 ~~~ 现在我们尝试把上面让鸭子和鸡叫唤的例子换成Java代码： ~~~ public class Duck { //鸭子类 public void makeSound(){ System.out.println( 嘎嘎嘎 ); } } public class Chicken { //鸡类 public void makeSound(){ System.out.println( 咯咯咯 ); } } public class AnimalSound { public void makeSound( Duck duck ){ //(1) duck.makeSound(); } } public class Test { public static void main( String args[] ){ AnimalSound animalSound = new AnimalSound(); Duck duck = new Duck(); animalSound.makeSound( duck ); //输出：嘎嘎嘎 } } ~~~ 我们已经顺利地让鸭子可以发出叫声，但如果现在想让鸡也叫唤起来，我们发现这是一件不可能实现的事情。因为(1)处AnimalSound类的makeSound方法，被我们规定为只能接受Duck类型的参数： ~~~ public class Test { public static void main( String args[] ){ AnimalSound animalSound = new AnimalSound(); Chicken chicken = new Chicken(); animalSound.makeSound( chicken ); //报错，只能接受Duck类型的参数 } } ~~~ 某些时候，在享受静态语言类型检查带来的安全性的同时，我们亦会感觉被束缚住了手脚。 为了解决这一问题，静态类型的面向对象语言通常被设计为可以向上转型：当给一个类变量赋值时，这个变量的类型既可以使用这个类本身，也可以使用这个类的超类。这就像我们在描述天上的一只麻雀或者一只喜鹊时，通常说“一只麻雀在飞”或者“一只喜鹊在飞”。但如果想忽略它们的具体类型，那么也可以说”一只鸟在飞“。 同理，当Duck对象和Chicken对象的类型都被隐藏在超类型Animal身后，Duck对象和Chicken对象就能被交换使用，这是让对象表现出多态性的必经之路，而多态性的表现正是实现众多设计模式的目标。 ### 4. 使用继承得到多态效果 使用继承来得到多态效果，是让对象表现出多态性的最常用手段。继承通常包括实现继承和接口继承。本节我们讨论实现继承，接口继承的例子请参见第21章。 我们先创建一个Animal抽象类，再分别让Duck和Chicken都继承自Animal抽象类，下述代码中(1)处和(2)处的赋值语句显然是成立的，因为鸭子和鸡也是动物： ~~~ public abstract class Animal { abstract void makeSound(); //抽象方法 } public class Chicken extends Animal{ public void makeSound(){ System.out.println( 咯咯咯 ); } } public class Duck extends Animal{ public void makeSound(){ System.out.println( 嘎嘎嘎 ); } } Animal duck = new Duck(); //(1) Animal chicken = new Chicken(); //(2) ~~~ 现在剩下的就是让AnimalSound类的makeSound方法接受Animal类型的参数，而不是具体的Duck类型或者Chicken类型： ~~~ public class AnimalSound{ public void makeSound( Animal animal ){ //接受Animal类型的参数 animal.makeSound(); } } public class Test { public static void main( String args[] ){ AnimalSound animalSound= new AnimalSound (); Animal duck = new Duck(); Animal chicken = new Chicken(); animalSound.makeSound( duck ); //输出嘎嘎嘎 animalSound.makeSound( chicken ); //输出咯咯咯 } } ~~~ ### 5. JavaScript的多态 从前面的讲解我们得知，多态的思想实际上是把“做什么”和“谁去做”分离开来，要实现这一点，归根结底先要消除类型之间的耦合关系。如果类型之间的耦合关系没有被消除，那么我们在makeSound方法中指定了发出叫声的对象是某个类型，它就不可能再被替换为另外一个类型。在Java中，可以通过向上转型来实现多态。 而JavaScript的变量类型在运行期是可变的。一个JavaScript对象，既可以表示Duck类型的对象，又可以表示Chicken类型的对象，这意味着JavaScript对象的多态性是与生俱来的。 这种与生俱来的多态性并不难解释。JavaScript作为一门动态类型语言，它在编译时没有类型检查的过程，既没有检查创建的对象类型，又没有检查传递的参数类型。在2节的代码示例中，我们既可以往makeSound函数里传递duck对象当作参数，也可以传递chicken对象当作参数。 由此可见，某一种动物能否发出叫声，只取决于它有没有makeSound方法，而不取决于它是否是某种类型的对象，这里不存在任何程度上的“类型耦合”。这正是我们从上一节的鸭子类型中领悟的道理。在JavaScript中，并不需要诸如向上转型之类的技术来取得多态的效果。 ### 6. 多态在面向对象程序设计中的作用 有许多人认为，多态是面向对象编程语言中最重要的技术。但我们目前还很难看出这一点，毕竟大部分人都不关心鸡是怎么叫的，也不想知道鸭是怎么叫的。让鸡和鸭在同一个消息之下发出不同的叫声，这跟程序员有什么关系呢？ Martin Fowler在《重构：改善既有代码的设计》里写到： 多态的最根本好处在于，你不必再向对象询问“你是什么类型”而后根据得到的答案调用对象的某个行为——你只管调用该行为就是了，其他的一切多态机制都会为你安排妥当。 换句话说，多态最根本的作用就是通过把过程化的条件分支语句转化为对象的多态性，从而消除这些条件分支语句。 Martin Fowler的话可以用下面这个例子很好地诠释： 在电影的拍摄现场，当导演喊出“action”时，主角开始背台词，照明师负责打灯光，后面的群众演员假装中枪倒地，道具师往镜头里撒上雪花。在得到同一个消息时，每个对象都知道自己应该做什么。如果不利用对象的多态性，而是用面向过程的方式来编写这一段代码，那么相当于在电影开始拍摄之后，导演每次都要走到每个人的面前，确认它们的职业分工（类型），然后告诉他们要做什么。如果映射到程序中，那么程序中将充斥着条件分支语句。 利用对象的多态性，导演在发布消息时，就不必考虑各个对象接到消息后应该做什么。对象应该做什么并不是临时决定的，而是已经事先约定和排练完毕的。每个对象应该做什么，已经成为了该对象的一个方法，被安装在对象的内部，每个对象负责它们自己的行为。所以这些对象可以根据同一个消息，有条不紊地分别进行各自的工作。 将行为分布在各个对象中，并让这些对象各自负责自己的行为，这正是面向对象设计的优点。 再看一个现实开发中遇到的例子，这个例子的思想和动物叫声的故事非常相似。 假设我们要编写一个地图应用，现在有两家可选的地图API提供商供我们接入自己的应用。目前我们选择的是谷歌地图，谷歌地图的API中提供了show方法，负责在页面上展示整个地图。示例代码如下： ~~~ var googleMap = { show: function(){ console.log( '开始渲染google地图' ); } }; var renderMap = function(){ googleMap.show(); }; renderMap(); // 输出： 开始渲染google地图 ~~~ 后来因为某些原因，要把谷歌地图换成百度地图，为了让renderMap函数保持一定的弹性，我们用一些条件分支来让renderMap函数同时支持谷歌地图和百度地图： ~~~ var googleMap = { show: function(){ console.log( '开始渲染google地图' ); } }; var baiduMap = { show: function(){ console.log( '开始渲染baidu地图' ); } }; var renderMap = function( type ){ if ( type === 'google' ){ googleMap.show(); }else if ( type === 'baidu' ){ baiduMap.show(); } }; renderMap( 'google' ); // 输出： 开始渲染google地图 renderMap( 'baidu' ); // 输出： 开始渲染baidu地图 ~~~ 可以看到，虽然renderMap函数目前保持了一定的弹性，但这种弹性是很脆弱的，一旦需要替换成搜搜地图，那无疑必须得改动renderMap函数，继续往里面堆砌条件分支语句。 我们还是先把程序中相同的部分抽象出来，那就是显示某个地图： ~~~ var renderMap = function( map ){ if ( map.show instanceof Function ){ map.show(); } }; renderMap( googleMap ); // 输出： 开始渲染google地图 renderMap( baiduMap ); // 输出： 开始渲染baidu地图 ~~~ 现在来找找这段代码中的多态性。当我们向谷歌地图对象和百度地图对象分别发出“展示地图”的消息时，会分别调用它们的show方法，就会产生各自不同的执行结果。对象的多态性提示我们，“做什么”和“怎么去做”是可以分开的，即使以后增加了搜搜地图，renderMap函数仍然不需要做任何改变，如下所示： ~~~ var sosoMap = { show: function(){ console.log( '开始渲染soso地图' ); } }; renderMap( sosoMap ); // 输出： 开始渲染soso地图 ~~~ 在这个例子中，我们假设每个地图API提供展示地图的方法名都是show，在实际开发中也许不会如此顺利，这时候可以借助适配器模式来解决问题。 文章摘自：javascript设计模式与开发实践

> 原文出处：[JavaScript设计模式浅谈](http://blog.csdn.net/column/details/js-patterns.html) 作者：[i10630226](http://blog.csdn.net/i10630226) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # JavaScript设计模式浅谈 > 本专栏主要介绍包括接口、封装、继承、单体模式、工厂模式、桥接模式、组合模式、门面模式等一些JavaScript的常见的模式。