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

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

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

　　不像c#，java等這種本身就擁有良好模塊化和命名空間機制的強類型語言。JavaScript并沒有為創(chuàng)建和管理模塊而提供任何語言功能。正因為這樣，我們在做js的編碼的某些時候，對于所謂的命名空間(namespace)的使用會顯得有些過于隨便(包括我自己)。比如 ：

　　var Hongru = {} // namespace

　　(function(){

　　Hongru.Class1 = function () {

　　//TODO

　　}

　　...

　　Hongru.Class2 = function () {

　　//TODO

　　}

　　})();

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

　　所以，我們在做一些項目的時候或者建一些規(guī)模不大的網(wǎng)站時，簡單的用這種方式來做namespace的工作其實也夠了，基本不會出什么大亂子。但是回歸本質(zhì)，如果是有代碼潔癖或者是建立一個大規(guī)模的網(wǎng)站，抑或一開始就抱著絕對優(yōu)雅的態(tài)度和邏輯來做代碼架構(gòu)的話。或許我們該考慮更好一些的namespace 的注冊和管理方式。

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

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

　　【關(guān)于namespace】

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