Javascript模块化及命名空间管理？

　　先说说我们为什么要模块化吧。其实这还是和编码思想和代码管理的便利度相关。命名空间管理优势怎样的？

　　其实模块化思想还是和面向对象的思想如出一辙，只不过可能我们口中所谓的“模块”是比所谓的“对象”更大的对象而已。我们把致力完成同一个目的的功能函数通过良好的封装组合起来，并且保证其良好的复用性，我们大概可以把这样一个组合代码片段的思想称为面向对象的思想。这样做的好处有很多，比如：易用性，通用性，可维护性，可阅读性，规避变量名污染等等。

　　而模块化无非就是在面向对象上的面向模块而已，我们把和同一个项目(模块)相关的功能封装有机的组合起来，通过一个共同的名字来管理。就大概可以说是模块化的思想。所以，相比面向对象而言的话，我觉得在代码架构上贯彻模块化的思想其实比面向对象的贯彻还更为容易一些。

　　不像c#，java等这种本身就拥有良好模块化和命名空间机制的强类型语言。JavaScript并没有为创建和管理模块而提供任何语言功能。正因为这样，我们在做js的编码的某些时候，对于所谓的命名空间(namespace)的使用会显得有些过于随便(包括我自己)。比如 ：

　　var Hongru = {} // namespace

　　(function(){

　　Hongru.Class1 = function () {

　　//TODO

　　}

　　...

　　Hongru.Class2 = function () {

　　//TODO

　　}

　　})();

　　如上，我们通常用一个全局变量或者全局对象就作为我们的namespace，如此简单，甚至显得有些随便的委以它这么重大的责任。但是我们能说这样做不好吗?不能，反而是觉得能有这种编码习惯的同学应该都值得表扬。。。

　　所以，我们在做一些项目的时候或者建一些规模不大的网站时，简单的用这种方式来做namespace的工作其实也够了，基本不会出什么大乱子。但是回归本质，如果是有代码洁癖或者是建立一个大规模的网站，抑或一开始就抱着绝对优雅的态度和逻辑来做代码架构的话。或许我们该考虑更好一些的namespace 的注册和管理方式。

　　在这个方面，jQuery相比于YUI，Mootool，EXT等，就显得稍逊一筹，(虽然jq也有自己的一套模块化机制)，但这依然不妨碍我们对它的喜爱，毕竟侧重点不同，jq强是强在它的选择器，否则他也不会叫j-Query了。

　　所以我们说jQuery比较适合中小型的网站也不无道理。就像豆瓣的开源的前端轻量级框架Do框架一样，也是建立在jQuery上，封装了一层模块化管理的思想和文件同步载入的功能。

　　【关于namespace】

　　好了，我们回归正题，如上的方式，简单的通过全局对象来做namespace已经能够很好的减少全局变量，规避变量名污染的问题，但是一旦网站规模变大，或者项目很多的时候，管理多个全局对象的名字空间依然会有问题。如果不巧发生了名字冲突，一个模块就会覆盖掉另一个模块的属性，导致其一或者两者都不能正常工作。而且出现问题之后，要去甄别也挺麻烦。所以我们可能需要一套机制或者工具，能在创建namespace的时候就能判断是否已有重名。