标签：步骤 测试 nod 代码 格式 initial 例子 type 响应
一、JS 模块包装格式都用过哪些，CommonJS、AMD、CMD。定义一个JS 模块代码，最精简的格式是怎样。
js模块化开发的起源。
CommonJs原来是叫ServerJs，从名字可以看出是专攻服务端的，为了统一前后端而改名CommonJs。（论起名的重要性~）
2009年，nodejs横空出世，开创了一个新纪元，人们可以用js来编写服务端的代码了。如果说浏览器端的js即便没有模块化也可以忍的话，那服务端是万万不能的。
大牛云集的CommonJs社区发力，制定了Modules/1.0（http://wiki.commonjs.org/wiki/Modules/1.0）规范，首次定义了一个模块应该长啥样。具体来说，Modules/1.0规范包含以下内容：
1. 模块的标识应遵循的规则（书写规范）
2. 定义全局函数require，通过传入模块标识来引入其他模块，执行的结果即为别的模块暴漏出来的API
3. 如果被require函数引入的模块中也包含依赖，那么依次加载这些依赖
4. 如果引入模块失败，那么require函数应该报一个异常
5. 模块通过变量exports来向往暴漏API，exports只能是一个对象，暴漏的API须作为此对象的属性。
此规范一出，立刻产生了良好的效果，由于其简单而直接，在nodejs中，这种模块化方案立刻被推广开了。
Modules/1.0规范源于服务端，无法直接用于浏览器端，原因表现为：
1. 外层没有function包裹，变量全暴漏在全局。如上面例子中increment.js中的add。
2. 资源的加载方式与服务端完全不同。服务端require一个模块，直接就从硬盘或者内存中读取了，消耗的时间可以忽略。而浏览器则不同，需要从服务端来下载这个文件，然后运行里面的代码才能得到API，需要花费一个http请求，也就是说，require后面的一行代码，需要资源请求完成才能执行。由于浏览器端是以插入<script>标签的形式来加载资源的（ajax方式不行，有跨域问题），没办法让代码同步执行，所以像commonjs那样的写法会直接报错。
所以，社区意识到，要想在浏览器环境中也能模块化，需要对规范进行升级。顺便说一句，CommonJs原来是叫ServerJs，从名字可以看出是专攻服务端的，为了统一前后端而改名CommonJs。（论起名的重要性~）
而就在社区讨论制定下一版规范的时候，内部发生了比较大的分歧，分裂出了三个主张，渐渐的形成三个不同的派别：
1.Modules/1.x派
这一波人认为，在现有基础上进行改进即可满足浏览器端的需要，既然浏览器端需要function包装，需要异步加载，那么新增一个方案，能把现有模块转化为适合浏览器端的就行了，有点像“保皇派”。基于这个主张，制定了Modules/Transport（http://wiki.commonjs.org/wiki/Modules/Transport）规范，提出了先通过工具把现有模块转化为复合浏览器上使用的模块，然后再使用的方案。
browserify就是这样一个工具，可以把nodejs的模块编译成浏览器可用的模块。（Modules/Transport规范晦涩难懂，我也不确定browserify跟它是何关联，有知道的朋友可以讲一下）
目前的最新版是Modules/1.1.1（http://wiki.commonjs.org/wiki/Modules/1.1.1），增加了一些require的属性，以及模块内增加module变量来描述模块信息，变动不大。
2. Modules/Async派
这一波人有点像“革新派”，他们认为浏览器与服务器环境差别太大，不能沿用旧的模块标准。既然浏览器必须异步加载代码，那么模块在定义的时候就必须指明所依赖的模块，然后把本模块的代码写在回调函数里。模块的加载也是通过下载-回调这样的过程来进行，这个思想就是AMD的基础，由于“革新派”与“保皇派”的思想无法达成一致，最终从CommonJs中分裂了出去，独立制定了浏览器端的js模块化规范AMD（Asynchronous Module Definition）（https://github.com/amdjs/amdjs-api/wiki/AMD）
本文后续会继续讨论AMD规范的内容。
3. Modules/2.0派
这一波人有点像“中间派”，既不想丢掉旧的规范，也不想像AMD那样推到重来。他们认为，Modules/1.0固然不适合浏览器，但它里面的一些理念还是很好的，（如通过require来声明依赖），新的规范应该兼容这些，AMD规范也有它好的地方（例如模块的预先加载以及通过return可以暴漏任意类型的数据，而不是像commonjs那样exports只能为object），也应采纳。最终他们制定了一个Modules/Wrappings（http://wiki.commonjs.org/wiki/Modules/Wrappings）规范，此规范指出了一个模块应该如何“包装”，包含以下内容：
1. 全局有一个module变量，用来定义模块
2. 通过module.declare方法来定义一个模块
3. module.declare方法只接收一个参数，那就是模块的factory，次factory可以是函数也可以是对象，如果是对象，那么模块输出就是此对象。
4. 模块的factory函数传入三个参数：require,exports,module，用来引入其他依赖和导出本模块API
5. 如果factory函数最后明确写有return数据（js函数中不写return默认返回undefined），那么return的内容即为模块的输出。
AMD的思想正如其名，异步加载所需的模块，然后在回调函数中执行主逻辑。这正是我们在浏览器端开发所习惯了的方式，其作者亲自实现了符合AMD规范的requirejs，AMD/RequireJs迅速被广大开发者所接受。
AMD规范包含以下内容：
1. 用全局函数define来定义模块，用法为：define(id?, dependencies?, factory);
2. id为模块标识，遵从CommonJS Module Identifiers规范
3. dependencies为依赖的模块数组，在factory中需传入形参与之一一对应
4. 如果dependencies的值中有"require"、"exports"或"module"，则与commonjs中的实现保持一致
5. 如果dependencies省略不写，则默认为["require", "exports", "module"]，factory中也会默认传入require,exports,module
6. 如果factory为函数，模块对外暴漏API的方法有三种：return任意类型的数据、exports.xxx=xxx、module.exports=xxx
7. 如果factory为对象，则该对象即为模块的返回值
基于以上几点基本规范，我们便可以用这样的方式来进行模块化组织代码了：
//a.js define(function(){ console.log(‘a.js执行‘); return { hello: function(){ console.log(‘hello, a.js‘); } } }); //b.js define(function(){ console.log(‘b.js执行‘); return { hello: function(){ console.log(‘hello, b.js‘); } } }); //main.js require([‘a‘, ‘b‘], function(a, b){ console.log(‘main.js执行‘); a.hello(); $(‘#b‘).click(function(){ b.hello(); }); })
上面的main.js被执行的时候，会有如下的输出：
a.js执行
b.js执行
main.js执行
hello, a.js
在点击按钮后，会输出：
hello, b.js
这结局，如你所愿吗？大体来看，是没什么问题的，因为你要的两个hello方法都正确的执行了。
但是如果细细来看，b.js被预先加载并且预先执行了，（第二行输出），b.hello这个方法是在点击了按钮之后才会执行，如果用户压根就没点，那么b.js中的代码应不应该执行呢？
这其实也是AMD/RequireJs被吐槽的一点，预先下载没什么争议，由于浏览器的环境特点，被依赖的模块肯定要预先下载的。问题在于，是否需要预先执行？如果一个模块依赖了十个其他模块，那么在本模块的代码执行之前，要先把其他十个模块的代码都执行一遍，不管这些模块是不是马上会被用到。这个性能消耗是不容忽视的。
另一点被吐槽的是，在定义模块的时候，要把所有依赖模块都罗列一遍，而且还要在factory中作为形参传进去，要写两遍很大一串模块名称，像这样：
define([‘a‘, ‘b‘, ‘c‘, ‘d‘, ‘e‘, ‘f‘, ‘g‘], function(a, b, c, d, e, f, g){ ..... })
编码过程略有不爽。
好的一点是，AMD保留了commonjs中的require、exprots、module这三个功能（上面提到的第4条）。你也可以不把依赖罗列在dependencies数组中。而是在代码中用require来引入，如下：
define(function(){ console.log(‘main2.js执行‘); require([‘a‘], function(a){ a.hello(); }); $(‘#b‘).click(function(){ require([‘b‘], function(b){ b.hello(); }); }); });
我们在define的参数中未写明依赖，那么main2.js在执行的时候，就不会预先加载a.js和b.js，只是执行到require语句的时候才会去加载，上述代码的输出如下：
main2.js执行
a.js执行
hello, a.js
可以看到b.js并未执行，从网络请求中看，b.js也并未被下载。只有在按钮被点击的时候b.js才会被下载执行，并且在回调函数中执行模块中的方法。这就是名副其实的“懒加载”了。
这样的懒加载无疑会大大减轻初始化时的损耗（下载和执行都被省去了），但是弊端也是显而易见的，在后续执行a.hello和b.hello时，必须得实时下载代码然后在回调中才能执行，这样的用户体验是不好的，用户的操作会有明显的延迟卡顿。
但这样的现实并非是无法接受的，毕竟是浏览器环境，我们已经习惯了操作网页时伴随的各种loading。。。
但是话说过来，有没有更好的方法来处理问题呢？资源的下载阶段还是预先进行，资源执行阶段后置，等到需要的时候再执行。这样一种折衷的方式，能够融合前面两种方式的优点，而又回避了缺点。
这就是Modules/Wrappings规范，还记得前面提到的“中间派”吗？
在AMD的阵营中，也有一部分人提出这样的观点，代码里写一堆回调实在是太恶心了，他们更喜欢这样来使用模块：
var a = require(‘a‘); a.hello(); $(‘#b‘).click(function(){ var b = require(‘b‘); b.hello(); });
于是，AMD也终于决定作妥协，兼容Modules/Wrappings的写法，但只是部分兼容，例如并没有使用module.declare来定义模块，而还是用define，模块的执行时机也没有改变，依旧是预先执行。因此，AMD将此兼容称为Simplified CommonJS wrapping，即并不是完整的实现Modules/Wrappings。
作了此兼容后，使用requirejs就可以这么写代码了：
//d.js define(function(require, exports, module){ console.log(‘d.js执行‘); return { helloA: function(){ var a = require(‘a‘); a.hello(); }, run: function(){ $(‘#b‘).click(function(){ var b = require(‘b‘); b.hello(); }); } } });
注意定义模块时候的轻微差异，dependencies数组为空，但是factory函数的形参必须手工写上require,exports,module，（这不同于之前的dependencies和factory形参全不写），这样写即可使用Simplified CommonJS wrapping风格，与commonjs的格式一致了。
虽然使用上看起来简单，然而在理解上却给后人埋下了一个大坑。因为AMD只是支持了这样的语法，而并没有真正实现模块的延后执行。什么意思呢？上面的代码，正常来讲应该是预先下载a.js和b.js，然后在执行模块的helloA方法的时候开始执行a.js里面的代码，在点击按钮的时候开始执行b.js中的方法。实际却不是这样，只要此模块被别的模块引入，a.js和b.js中的代码还是被预先执行了。
我们把上面的代码命名为d.js，在别的地方使用它：
require([‘d‘], function(d){ });
上面的代码会输出
a.js执行
b.js执行
d.js执行
可以看出，尽管还未调用d模块的API，里面所依赖的a.js和b.js中的代码已经执行了。AMD的这种只实现语法却未真正实现功能的做法容易给人造成理解上的困难，被强烈吐槽。
（在requirejs2.0中，作者声明已经处理了此问题（https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#delayed），但是我用2.1.20版测试的时候还是会预先执行，我有点不太明白原因，如果有懂的高手请指教）
兼容并包的CMD/seajs
既然requirejs有上述种种不甚优雅的地方，所以必然会有新东西来完善它，这就是后起之秀seajs，seajs的作者是国内大牛淘宝前端步道者玉伯。seajs全面拥抱Modules/Wrappings规范，不用requirejs那样回调的方式来编写模块。而它也不是完全按照Modules/Wrappings规范，seajs并没有使用declare来定义模块，而是使用和requirejs一样的define，或许作者本人更喜欢这个名字吧。（然而这或多或少又会给人们造成理解上的混淆），用seajs定义模块的写法如下：
//a.js define(function(require, exports, module){ console.log(‘a.js执行‘); return { hello: function(){ console.log(‘hello, a.js‘); } } }); //b.js define(function(require, exports, module){ console.log(‘b.js执行‘); return { hello: function(){ console.log(‘hello, b.js‘); } } }); //main.js define(function(require, exports, module){ console.log(‘main.js执行‘); var a = require(‘a‘); a.hello(); $(‘#b‘).click(function(){ var b = require(‘b‘); b.hello(); }); });
定义模块时无需罗列依赖数组，在factory函数中需传入形参require,exports,module，然后它会调用factory函数的toString方法，对函数的内容进行正则匹配，通过匹配到的require语句来分析依赖，这样就真正实现了commonjs风格的代码。
上面的main.js执行会输出如下：
main.js执行
a.js执行
hello, a.js
a.js和b.js都会预先下载，但是b.js中的代码却没有执行，因为还没有点击按钮。当点击按钮的时候，会输出如下：
b.js执行
hello, b.js
可以看到b.js中的代码此时才执行。这样就真正实现了“就近书写，延迟执行“，不可谓不优雅。
如果你一定要挑出一点不爽的话，那就是b.js的预先下载了。你可能不太想一开始就下载好所有的资源，希望像requirejs那样，等点击按钮的时候再开始下载b.js。本着兼容并包的思想，seajs也实现了这一功能，提供require.async API，在点击按钮的时候，只需这样写：
var b = require.async(‘b‘); b.hello();
b.js就不会在一开始的时候就加载了。这个API可以说是简单漂亮。
b.js就不会在一开始的时候就加载了。这个API可以说是简单漂亮。
关于模块对外暴漏API的方式，seajs也是融合了各家之长，支持commonjs的exports.xxx = xxx和module.exports = xxx的写法，也支持AMD的return写法，暴露的API可以是任意类型。
你可能会觉得seajs无非就是一个抄，把别人家的优点都抄过来组合了一下。其实不然，seajs是commonjs规范在浏览器端的践行者，对于requirejs的优点也加以吸收。看人家的名字，就是海纳百川之意。（再论起名的重要性~），既然它的思想是海纳百川，讨论是不是抄就没意义了。
鉴于seajs融合了太多的东西，已经无法说它遵循哪个规范了，所以玉伯干脆就自立门户，起名曰CMD（Common Module Definition）规范，有了纲领，就不会再存在非议了。
AMD
AMD 即Asynchronous Module Definition，中文名是异步模块定义的意思。它是一个在浏览器端模块化开发的规范
由于不是JavaScript原生支持，使用AMD规范进行页面开发需要用到对应的库函数，也就是大名鼎鼎RequireJS，实际上AMD 是 RequireJS 在推广过程中对模块定义的规范化的产出
requireJS主要解决两个问题
多个js文件可能有依赖关系，被依赖的文件需要早于依赖它的文件加载到浏览器
js加载的时候浏览器会停止页面渲染，加载文件越多，页面失去响应时间越长
看一个使用requireJS的例子
// 定义模块 myModule.js define([‘dependency‘], function(){ var name = ‘Byron‘; function printName(){ console.log(name); } return { printName: printName }; }); // 加载模块 require([‘myModule‘], function (my){ my.printName(); });
语法
requireJS定义了一个函数 define，它是全局变量，用来定义模块
define(id?, dependencies?, factory);
id：可选参数，用来定义模块的标识，如果没有提供该参数，脚本文件名（去掉拓展名）
dependencies：是一个当前模块依赖的模块名称数组
factory：工厂方法，模块初始化要执行的函数或对象。如果为函数，它应该只被执行一次。如果是对象，此对象应该为模块的输出值
在页面上使用require函数加载模块
require([dependencies], function(){});
require()函数接受两个参数
第一个参数是一个数组，表示所依赖的模块
第二个参数是一个回调函数，当前面指定的模块都加载成功后，它将被调用。加载的模块会以参数形式传入该函数，从而在回调函数内部就可以使用这些模块
require()函数在加载依赖的函数的时候是异步加载的，这样浏览器不会失去响应，它指定的回调函数，只有前面的模块都加载成功后，才会运行，解决了依赖性的问题。
CMD
CMD 即Common Module Definition通用模块定义，CMD规范是国内发展出来的，就像AMD有个requireJS，CMD有个浏览器的实现SeaJS，SeaJS要解决的问题和requireJS一样，只不过在模块定义方式和模块加载（可以说运行、解析）时机上有所不同
语法
Sea.js 推崇一个模块一个文件，遵循统一的写法
define
define(id?, deps?, factory)
因为CMD推崇
一个文件一个模块，所以经常就用文件名作为模块id
CMD推崇依赖就近，所以一般不在define的参数中写依赖，在factory中写
factory有三个参数
function(require, exports, module)
require
require 是 factory 函数的第一个参数
require(id)
require 是一个方法，接受 模块标识 作为唯一参数，用来获取其他模块提供的接口
exports
exports 是一个对象，用来向外提供模块接口
module
module 是一个对象，上面存储了与当前模块相关联的一些属性和方法
demo
// 定义模块 myModule.js define(function(require, exports, module) { var $ = require(‘jquery.js‘) $(‘div‘).addClass(‘active‘); }); // 加载模块 seajs.use([‘myModule.js‘], function(my){ });
AMD与CMD区别
关于这两个的区别网上可以搜出一堆文章，简单总结一下
最明显的区别就是在模块定义时对依赖的处理不同
AMD推崇依赖前置，在定义模块的时候就要声明其依赖的模块
CMD推崇就近依赖，只有在用到某个模块的时候再去require
这种区别各有优劣，只是语法上的差距，而且requireJS和SeaJS都支持对方的写法
AMD和CMD最大的区别是对依赖模块的执行时机处理不同，注意不是加载的时机或者方式不同
很多人说requireJS是异步加载模块，SeaJS是同步加载模块，这么理解实际上是不准确的，其实加载模块都是异步的，只不过AMD依赖前置，js可以方便知道依赖模块是谁，立即加载，而CMD就近依赖，需要使用把模块变为字符串解析一遍才知道依赖了那些模块，这也是很多人诟病CMD的一点，牺牲性能来带来开发的便利性，实际上解析模块用的时间短到可以忽略
为什么我们说两个的区别是依赖模块执行时机不同，为什么很多人认为ADM是异步的，CMD是同步的（除了名字的原因。。。）
同样都是异步加载模块，AMD在加载模块完成后就会执行改模块，所有模块都加载执行完后会进入require的回调函数，执行主逻辑，这样的效果就是依赖模块的执行顺序和书写顺序不一定一致，看网络速度，哪个先下载下来，哪个先执行，但是主逻辑一定在所有依赖加载完成后才执行
CMD加载完某个依赖模块后并不执行，只是下载而已，在所有依赖模块加载完成后进入主逻辑，遇到require语句的时候才执行对应的模块，这样模块的执行顺序和书写顺序是完全一致的
这也是很多人说AMD用户体验好，因为没有延迟，依赖模块提前执行了，CMD性能好，因为只有用户需要的时候才执行的原因
二、JS 怎么实现一个类。怎么实例化这个类。
在JavaScript中, 当你定义了一个新的函数, 你实际上声明了一个新的类, 而这个函数本身就相当于类的构造函数。下面的代码向你展示了两种不同的方式来创建一个新的Person类, 而Person.prototype的定义也紧跟在函数定义之后。
var Person = function(name) { // 一个匿名函数, 并将这个函数赋值给一个Person变量, 此时Person成为一个类 this.name = name; } function Person(name) { // 直接定义一个叫做Person的函数表示Person类 this.name = name; } Person.prototype = { // 定义Person的prototype域 printName: function() { // 定义一个print函数 alert(this.name); } }
当你通过函数的方式声明了一个类之后, 你就可以通过new操作符来实例化这个类。这样, 你就可以调用类的成员函数来完成你的逻辑。
var person = new Person("Joe Smith"); // 使用new操作符来新建一个Person的实例, 并赋给变量person
person.printName(); // person就可以看作是一个实例的引用(reference), 所以可以通过这个引用来调用Person类中的成员函数
我们来总结一下创建一个新的类的实例的整个流程和步骤：
1. 通过定义一个函数的方式(匿名或者实名)来声明一个新的类.
2. 如果有必要, 定义这个新的类的prototype域.
3. 使用new操作符紧跟你所定义的函数来创建一个新的类的实例. 一旦JavaScript编译器碰到了new操作符, 它实际上创建了一个空的类实例变量.
4. 将所有这个类的prototype域中的属性与方法复制到这个新的实例中, 并将其成员函数中所有的this指针指向这个新创建的实例.
5. 接下来, 执行紧跟在new操作符后面的那个函数.
6. 当你执行这个函数时, 如果你试图对一个不存在的属性进行赋值, JavaScript编译器将自动为你在这个实例范围内新创建这个属性.
7. 函数执行完毕后, 将这个初始化完成的实例返回.
在Prototype中, 使用Class对象, 你可以以一个比较简单的方式来声明一个新的对象。通过使用Class.create(), prototype为你创建了一个默认的构造函数initialize(), 一旦你实现这一函数, 就可以以一个类似Java中构造函数的方式来创建一个新的类的实例。
标签：步骤 测试 nod 代码 格式 initial 例子 type 响应
原文地址：http://www.cnblogs.com/xin9984/p/6216520.html
