RequireJS中定义一个模块，总的来说有2种方式：简单键值对和函数依赖式。
 
1.简单键值对：一个模块仅含有值对，没有任何依赖
 
 
define({
    color: "black",
    size: 1,
    method1: function() {},
    method2: function() {}
});
 
这种写法虽然简单，但是有很大的局限性，仅仅是定义了该模块的返回值，不能做一些额外的初始化工作。
 
通过下面下面这种方式来定义模块，灵活性更高，我们可以在函数体内写一些模块初始化的代码。
 
 
define(function () {

    //Do initial work here

    return {
        method1: function() {},
        method2: function() {}
    };
});
 
 

 
 
2.函数依赖式：则第一个参数是依赖的名称数组；第二个参数是回调函数。 
在模块的所有依赖加载完毕后，回调函数会被调用来定义该模块。
 
 
define(["module1"], function(moudle1) {
        
		function calc()
		{
			return moudle1.val;
		}
		
		return {"get":calc};
    }
);

 

 
这2种定义模块的方式是等价的，requirejs能够保证一个模块只会被加载一次，所以如果A、B模块都依赖于C模块，那么其实A和B模块使用的都是同一个对象。
 
 
//C模块
define([],function(){
 
	var count = 0;
	
	function sayCount()
	{
		count++;
		return count;
	}

	return {"say":sayCount};

});
 
// A模块
require(['C'],
  function(module) {
         cosole.log(module.say());//1
});
 
// B模块
require(['C'],
  function(module) {
		cosole.log(module.say());//2
});
 

 
 

 
 
如果我们定义了一个模块，很多时候我们希望它能够被多个模块使用而不会相互干扰。 
 
//C模块
define([],function(){
 
 // 定义一个类
 function DemoClass()
 {
	var count = 0;
	this.say = function(){
		count++;
		return count;
	};
 }
 
 return function(){
	//每次都返回一个新对象
	return new DemoClass();
 };

});
 
// A模块
require(['C'],
  function(module) {
         cosole.log(module().say());//1
});
 
// B模块
require(['C'],
  function(module) {
		cosole.log(module().say());//1
});

 
每次调用模块C，返回都是一个新的对象，通过这种方式能够避免A和B模块在使用模块C时候的干扰和冲突。
 

 
 

对于头文件中为什么可以定义const变量（或对象），以及推荐用const代替#define宏定义，之前一直概念不清晰，今天就总结一下。
 
之前在网上查过，解释的都不太到位，或者角度不一样（从编译原理、强弱定义？），总之不能清晰理解，发现《C++ Primer》上基本上涵盖了所有平常遇到的C/C++问题，而且《C++ Primer》地位正宗，上面的解释可信度自然没得说。so，有问题，先找《C++ Primer》。
 1.
const对象默认为文件的局部变量。《C++ Primer 4》p86，

 
2.头文件用于声明而不是用于定义。《C++ Primer 4》p100，原因是：
 
 
 
 
1.定义和声明的区别：定义只可以出现一次，而声明则可以出现多次。下面这些是定义(怎样判断的？)，都不应该出现在头文件中：
 
 
extern int ival = 10;
 
 
double fica_rate;
 
 
 
 
 
同一个程序中有两个以上文件含有上述任一个定义都会导致多重定义链接错误。编译时可能不会报错，因为编译时每个源文件都是单独编译生成目标文件，彼此是相互独立不可见的，只有在链接的时候整个工程才作为一个整体，链接主要解决模块间的相互引用问题，而在编译阶段生成目标文件是，会暂时搁置那些外部引用，外部引用是在链接时进行确定的。
 
 
因为头文件包含在多个源文件中，所以不应该含有变量或函数的定义。但是……
 
 
3.对于头文件不应该含有定义这一规则，有三个例外。头文件中可以定义类、值在编译时就已知道的const对象（数组的大小可以用const int型变量定义，这在C中是不行的），和inline函数。《C++ Primer 4》p100，在补充一个，模板"必须"定义在头文件中，包括模板类和模板函数。
 
下面来解释原因：
 
 
 
1.这些实体可以在多个源文件中定义，只要每个源文件中的定义是相同的。
 
 
2.在头文件中定义这些实体，是因为编译器需要他们的定义（不只是声明）来产生代码（这句话对模板同样适用）。例如：为了产生能定义或使用类的对象的代码，编译器需要知道组成该类型的数据成员。同样还需要知道能够在这些对象上执行的操作。类定义提供所需要的信息。当然（但是）类定义内部的成员可以是声明，类定义和类内部成员的定义不是一回事哦，可以不同步进行，也”不建议“类定义时定义类内部函数。在头文件中定义const对象则需要更多解释。
 
 
3.下面是本节的重点了（引自《C++ Primer 4》,满满的都是干货）：
 
 
const 变量默认时是定义该变量的文件的局部变量。正如我们现在所看到的，这样设置默认情况的原因在于允许 const 变量定义在头文件中。
 
 
 
在 C++ 中，有些地方需要放置常量表达式。例如，枚举成员的初始化式必须是常量表达式。在以后的章节中将会看到其他需要常量表达式的
 例子。
 
 
 
一般来说，常量表达式是编译器在编译时就能够计算出结果的表达式。当 const 整型变量通过常量表达式自我初始化时，这个 const 整型变量就可能是常量表达式。而 const 变量要成为常量表达式，初始化式必须为编译器可见。 为了能够让多个文件使用相同的常量值，const 变量和它的初始化式必须是每个文件都可见的。而要使初始化式可见，一般都把这样的 const 变量定义在头文件中。那样的话，无论该 const 变量何时使用，编译器都能够看见其初始化式。
 
 
 
但是，C++ 中的任何变量都只能定义一次（第 2.3.5 节）。定义会分配存储空间，而所有对该变量的使用都关联到同一存储空间。因为 const 对象默认为定义它的文件的局部变量，所以把它们的定义放在头文件中是合法的。 
 
 
这种行为有一个很重要的含义：当我们在头文件中定义了 const 变量后，每个包含该头文件的源文件都有了自己的 const 变量，其名称和值都一样。 
 
 
当该 const 变量是用常量表达式初始化时，可以保证所有的变量都有相同的值。但是在实践中，大部分的编译器在编译时都会用相应的常量表达式替换这些 const 变量的任何使用。所以，在实践中不会有任何存储空间用于存储用常量表达式初始化的 const 变量。 
 如果 const 变量不是用常量表达式初始化，那么它就不应该在头文件中定义（若不初始化const变量，这个const变量有什么用呢？）。相反，和其他的变量一样，该 const 变量应该在一个源文件中定义并初始化。应在头文件中为它添加 extern 声明，以使其能被多个文件共享。
 
 
 

 
 
下面再补充点关于编译和链接方面的知识:
 
 
 
编译：将预处理生成的文件，经过词法、语法、语义分析及优化后编译成若个目标模块（linux中的 .o 或win32中的 .obj）。
 
 
链接：由链接程序将编译后形成的一组目标模块以及他们所需要的库函数链接在一起，形成一个完整的载入模型。（win32中的可执行程序 .exe）
 
 
编译可以理解为，将高级语言翻译成计算机可以理解的二进制代码，即机器语言。编译器需要的是语法正确，函数与变量的声明正确。
 
 
链接时主要链接函数和全局变量，目标文件之间相互链接自己所需要的函数和全局变量，而函数可能来自其他目标文件或库文件。
 
 
链接可分为：
 
 
 
 
 
 
静态链接
载入时动态链接
运行时动态链接
 
 
 
 

谈及前端模块化，自然会想到AMD（异步模块定义）和CMD（通用模块定义），这里我着重谈一下AMD的相关内容
 
AMD的整体目标是提供模块化的JavaScript解决方案，以便开发人员使用。
 
关于AMD有两个关键概念是值得我们注意的，它们是用于模块定义的define方法和用于处理依赖加载的require方法。使用以下方式，define用于定义已命名或未命名模块。
 
 
define(
	module_id//可选
	[dependencies]//可选
	function(){}//实例化模块或对象的函数
	);

 module_id是一个可选参数，当遗漏这个参数时，我们程这个参数是匿名的。 
 
回到define方法，dependencies参数表示我们定义模块所需的依赖数组，第三个参数适用于执行实例化模块的函数。示例如下：
 
 
define(
	"myModule",
	['foo','bar'],
	function (foo,bar){
		var myModule={
			fn:function(){
				console.log("hello");
			}
		};
	    return myModule;
	}
)
另外一种方式，return直接返回要暴露的内容。 
 
 
define(
    "myModule",
    ['math', 'graph'],
    function(math, graph) {
	   return {
		    plot: function(x, y) {
			return graph.draw(math.grid(x, y))
		    }
	    }
    };
})
那如果我们希望动态获取依赖呢，这样做依赖的加载会不会更灵活高效。 
 
 
define(function(require){
	var isReady=false;
	var foobar;
	require(["foo","bar"],function(foo,bar){
		 isReady=true;
		 foobar=foo()+bar();
	});
	//依然返回一个模块
	return{
        isReady:isReady;
        foobar:foobar;
	}
});
模块定义好以后，如何加载使用呢，这里有curl.js和RequireJS两种类型的加载器。 
 
以最熟悉的requireJS为例，加载上面定义好的myModule模块
 
require（["app/myModule"],function(myModule){

  var module=new myModule();
  module.fn();


}）
 
为何AMD是编写模块化JavaScript的更好选择
 
·对于如何完成灵活模块的定义提供了明确的建议
 
·比很多人依赖的现有全局命名空间和<script>标签解决方案都更加简洁。有一种简洁的方式可以声明可能的独立模块和依赖。
 
·封装模块的定义，帮助我们避免全局命名空间被污染
 
·如果需要，可以延迟加载脚本
 
 

 
 

 

常规方法：
 
以导入numpy 为例
 
(1)import numpy
 
(2) import numpy as np(别名，自己定义) 
 
(3)import numpy *(不推荐)
 
动态导入：
 
待补充