关于Cold的结构和模块载入机制（上）
来自本人博客：http://ilovespringna.com/typecho/index.php/archives/34349/
这几个月一直在鼓捣的Cold框架，在自己的思考和借鉴了一些已有框架的方法后，算是有些成果了。尝试先写点小结，作为阶段性的巩固，因为代码越写越多，连自己都有些看不懂了。 在开始理清Cold的结构前，有几个关键的问题：
1、模块的颗粒度问题。
因为Cold现阶段的本质是利用前端的方式解决按需载入这一需求，因此每一个模块对应一个js文件，在应用中也相应地多出一个请求。如果像类似百度tangram以方法为粒度进行调度，便会多出成百上千个请求。或是极端考虑，整个框架为粒度（jquery，单文件模式），按需调用就没有意义。因此，需要在代码冗余度和请求数之间做平衡。2、命名空间和模块名。
这里有三个术语：模块的文件路径，模块名，模块对象。其中模块名是唯一标识模块的主键，模块对象是在内存里命名空间中安排的位置，文件路径则是文件的物理位置，用于引用文件。 因此一个模块的元数据可能如下：{
name : 'dragable',
filesrc : '/cold/component/dragable.js',
namespace : 'Cold.dragable'
};
这样在声明和使用一个模块时，开发者需要分别指明这个模块的名称，路径，和模块对象，既容易冲突、难以记忆，而且需要多余的文件进行管理存储，这是我不喜欢的。
比如我声明了另一个模块dialog时，其依赖于模块dragable，那么理想的代码如下：
define('dialog',{ requires : ['dragable'] },function(){
//do sth.
});
define在得到dialog的依赖项dragable后，并不知道dragable在哪，也不知道dragable在什么命名空间下，需要去别的文件中找到这个关系才能进行引用。因此Cold框架希望能够将这三个名称进行统一，本质上是模块定义的单一性。
3、模块依赖。
上面提到了我理想的模块依赖模型：开发者只需要在一处地方定义新的模块，只需要提供一个统一的模块标识符，在他的定义代码中能够做完所有的事，不需要重复定义和存储。模块依赖模型需要处理两个问题：递归依赖和循环依赖。 递归依赖，即模块a需要模块b，模块b需要模块c，形成一条a—b—c的依赖链。在这种情况下，c的定义代码必须先执行，然后是b，然后是a，而文件载入的顺序则可以随意。 循环依赖，即模块a需要模块b，模块b又需要模块a，这样就形成了无穷依赖，实际上是一个逻辑错误。 解决上面三个问题是Cold模块载入机制的目标。下一篇文章具体阐述Cold的结构和模块载入机制。
