JavaScript 모듈 사양 AMD 사양 및 CMD 사양_javascript 기술

모듈화는 복잡한 문제나 일련의 혼합된 문제를 해결할 때 분류적 사고에 따라 문제를 체계적으로 분해하고 처리하는 것을 의미합니다. 모듈화는 복잡한 시스템을 보다 합리적인 코드 구조와 높은 유지 관리 가능성을 갖춘 관리 가능한 모듈로 분해하는 방법입니다. 거대한 시스템 코드가 통합, 최적화되고 매우 논리적인 모듈로 분할될 때 소프트웨어에 얼마나 의미가 있는지 상상할 수 있습니다. 소프트웨어 산업의 경우: 분리된 소프트웨어 시스템의 복잡성으로 인해 시스템 규모에 관계없이 관리, 개발 및 유지 관리가 "합리적"입니다.

모듈성에 대한 몇 가지 전문적인 정의도 있습니다. 모듈성은 소프트웨어 시스템의 속성입니다. 이 시스템은 응집력이 높고 결합이 적은 모듈 세트로 분해됩니다. 따라서 이상적인 세계에서는 자체 핵심 비즈니스 로직 코드의 일부만 완성하면 되며, 다른 종속성은 다른 사람이 작성한 모듈을 직접 로드하여 사용할 수 있습니다.

1. AMD

AMD에는 인터페이스가 하나뿐입니다: 정의(id?,종속성?,공장);

모듈을 선언할 때 모든 종속성(dep)을 지정하고 다음과 같이 이를 공식 매개변수로 팩토리에 전달해야 합니다.

종속성이 없으면 다음과 같이 간단한 모듈을 정의하면 됩니다

define(function(){
  var exports = {};
  exports.method = function(){...};
  return exports;
});

여기에 정의가 있습니다. Node 구현에서 정의 키워드도 볼 수 있습니다. 사실 이는 Node에 의한 암시적 패키징일 뿐입니다.

RequireJS는 AMD 사양을 구현합니다

2.CMD

유 삼촌이 제안한 CMD 사양을 따르는 seajs를 작성했는데, AMD보다 약간 더 강력하고 사용하기 더 편리하다고 느껴집니다.

3. AMD와 CMD의 차이점

CMD는 주문형 로딩과 동일합니다. 모듈을 정의할 때 즉시 종속 모듈을 구성할 필요는 없으며 필요할 때만 요구하면 됩니다. 반대로 AMD에서는 종속 모듈을 구성해야 합니다. 모듈을 정의하고 형식 매개변수의 방법을 공장에 도입합니다

//AMD 모드 정의 모듈

define(['dep1','dep2'],function(dep1,dep2){
  //内部只能使用制定的模块
  return function(){};
});

//CMD

define(function(require,exports,module){
 //此处如果需要某XX模块，可以引入
 var xx=require('XX');
});

그리고 SEAJS에는
과 같은 모든 종속 모듈을 먼저 도입해야 하는 사용 기능도 있습니다.

//SEAJS.Use方式
seajs.use(['dep1','dep2'],function(dep1,dep2){
  //这里实现事务
});

四、插件支持

但全球有两种比较流行的 JavaScript 模块化体系，一个是 Node 实现的 CommonJS，另外一个是 AMD。很多类库都同时支持 AMD 和 CommonJS，但是不支持 CMD。或许国内有很多 CMD 模块，但并没有在世界上流行起来。

现在比较火的 React 及周边类库，就是直接使用 CommonJS 的模块体系，使用 npm 管理模块，使用 Browserify 打包输出模块。
不久的将来 ES6 中新的模块化标准，可能就都得遵循新的标准了，什么AMD、CMD可能到时也不会怎么用了。

但是目前来说，前端开发没有用模块化编程就真的out的了，而目前的模块化编程，本人还是建议用SEAJS，虽然很多插件需要追加或修改一小块代码才能支持。但改过一次就能反复使用，也不会影响其它标准的支持。总体还算是比较方便实用的。

单独解释AMD 与 CMD 区别到底在哪里？

看了以上 AMD，requireJS 与 CMD， seaJS的简单介绍会有点感觉模糊，总感觉较为相似。因为像 requireJS 其并不是只是纯粹的AMD固有思想，其也是有CMD规范的思想，只不过是推荐 AMD规范方式而已， seaJS也是一样。

下面是玉伯对于 AMD 与 CMD 区别的解释：

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出。

CMD 是 SeaJS 在推广过程中对模块定义的规范化产出。

类似的还有 CommonJS Modules/2.0 规范，是 BravoJS 在推广过程中对模块定义的规范化产出还有不少??

这些规范的目的都是为了 JavaScript 的模块化开发，特别是在浏览器端的。

目前这些规范的实现都能达成浏览器端模块化开发的目的。

区别：

1. 对于依赖的模块，AMD 是提前执行，CMD 是延迟执行。不过 RequireJS 从 2.0 开始，也改成可以延迟执行（根据写法不同，处理方式不同）。CMD 推崇 as lazy as possible.

2. CMD 推崇依赖就近，AMD 推崇依赖前置。看代码：

// CMD

define(function(require, exports, module) {
 var a = require('./a')
 a.doSomething()
 // 此处略去 100 行
 var b = require('./b') // 依赖可以就近书写
 b.doSomething()
 // ...
})

// AMD 默认推荐的是

define(['./a', './b'], function(a, b) { // 依赖必须一开始就写好
 a.doSomething()
 // 此处略去 100 行
 b.doSomething()
 // ...
})

虽然 AMD 也支持 CMD 的写法，同时还支持将 require 作为依赖项传递，但 RequireJS 的作者默认是最喜欢上面的写法，也是官方文档里默认的模块定义写法。

    3. AMD 的 API 默认是一个当多个用，CMD 的 API 严格区分，推崇职责单一。比如 AMD 里，require 分全局 require 和局部 require，都叫 require。CMD 里，没有全局 require，而是根据模块系统的完备性，提供 seajs.use 来实现模块系统的加载启动。

CMD 里，每个 API 都简单纯粹。

    4. 还有一些细节差异，具体看这个规范的定义就好，就不多说了。