先說(shuō)說(shuō)我們?yōu)槭裁匆�模塊化吧。其實(shí)這還是和編碼思想和代碼管理的便利度相關(guān)。命名空間管理優(yōu)勢(shì)怎樣的？

　　其實(shí)模塊化思想還是和面向?qū)ο蟮乃枷肴绯鲆晦H，只不過(guò)可能我們口中所謂的“模塊”是比所謂的“對(duì)象”更大的對(duì)象而已。我們把致力完成同一個(gè)目的的功能函數(shù)通過(guò)良好的封裝組合起來(lái)，并且保證其良好的復(fù)用性，我們大概可以把這樣一個(gè)組合代碼片段的思想稱為面向?qū)ο蟮乃枷�。這樣做的好處有很多，比如：易用性，通用性，可維護(hù)性，可閱讀性，規(guī)避變量名污染等等。

　　而模塊化無(wú)非就是在面向?qū)ο笊系拿嫦蚰�塊而已，我們把和同一個(gè)項(xiàng)目(模塊)相關(guān)的功能封裝有機(jī)的組合起來(lái)，通過(guò)一個(gè)共同的名字來(lái)管理。就大概可以說(shuō)是模塊化的思想。所以，相比面向?qū)ο蠖�言的話，我覺(jué)得在代碼架構(gòu)上貫徹模塊化的思想其實(shí)比面向?qū)ο蟮呢瀼剡�更為容易一些。

　　不像c#，java等這種本身就擁有良好模塊化和命名空間機(jī)制的強(qiáng)類型語(yǔ)言。JavaScript并沒(méi)有為創(chuàng)建和管理模塊而提供任何語(yǔ)言功能。正因?yàn)檫@樣，我們?cè)谧鰆s的編碼的某些時(shí)候，對(duì)于所謂的命名空間(namespace)的使用會(huì)顯得有些過(guò)于隨便(包括我自己)。比如 ：

　　var Hongru = {} // namespace

　　(function(){

　　Hongru.Class1 = function () {

　　//TODO

　　}

　　...

　　Hongru.Class2 = function () {

　　//TODO

　　}

　　})();

　　如上，我們通常用一個(gè)全局變量或者全局對(duì)象就作為我們的namespace，如此簡(jiǎn)單，甚至顯得有些隨便的委以它這么重大的責(zé)任。但是我們能說(shuō)這樣做不好嗎?不能，反而是覺(jué)得能有這種編碼習(xí)慣的同學(xué)應(yīng)該都值得表?yè)P(yáng)。。。

　　所以，我們?cè)谧鲆恍╉?xiàng)目的時(shí)候或者建一些規(guī)模不大的網(wǎng)站時(shí)，簡(jiǎn)單的用這種方式來(lái)做namespace的工作其實(shí)也夠了，基本不會(huì)出什么大亂子。但是回歸本質(zhì)，如果是有代碼潔癖或者是建立一個(gè)大規(guī)模的網(wǎng)站，抑或一開(kāi)始就抱著絕對(duì)優(yōu)雅的態(tài)度和邏輯來(lái)做代碼架構(gòu)的話�；蛟S我們?cè)摽紤]更好一些的namespace 的注冊(cè)和管理方式。

　　在這個(gè)方面，jQuery相比于YUI，Mootool，EXT等，就顯得稍遜一籌，(雖然jq也有自己的一套模塊化機(jī)制)，但這依然不妨礙我們對(duì)它的喜愛(ài)，畢竟側(cè)重點(diǎn)不同，jq強(qiáng)是強(qiáng)在它的選擇器，否則他也不會(huì)叫j-Query了。

　　所以我們說(shuō)jQuery比較適合中小型的網(wǎng)站也不無(wú)道理。就像豆瓣的開(kāi)源的前端輕量級(jí)框架Do框架一樣，也是建立在jQuery上，封裝了一層模塊化管理的思想和文件同步載入的功能。

　　【關(guān)于namespace】

　　好了，我們回歸正題，如上的方式，簡(jiǎn)單的通過(guò)全局對(duì)象來(lái)做namespace已經(jīng)能夠很好的減少全局變量，規(guī)避變量名污染的問(wèn)題，但是一旦網(wǎng)站規(guī)模變大，或者項(xiàng)目很多的時(shí)候，管理多個(gè)全局對(duì)象的名字空間依然會(huì)有問(wèn)題。如果不巧發(fā)生了名字沖突，一個(gè)模塊就會(huì)覆蓋掉另一個(gè)模塊的屬性，導(dǎo)致其一或者兩者都不能正常工作。而且出現(xiàn)問(wèn)題之后，要去甄別也挺麻煩。所以我們可能需要一套機(jī)制或者工具，能在創(chuàng)建namespace的時(shí)候就能判斷是否已有重名。