據說每個大牛、小牛都應該有自己的庫——架構篇

最近寫了一系列的關于JavaScript文章，時不時就會蹦出個需求，需要寫個特定的小函數，或者是為了解決浏覽器相容性問題，或者是簡化一些操作，前面寫的幾篇部落格實際上已經寫出了一些常用的函數，既然自己希望在兩年内變成個技術小牛，提前準備自己的庫函數吧。

是個庫函數都會有自己的架構，我常用的有兩種形式，一種可以歸結為靜态方法型，大概定義一個立即執行函數，對外提供一個對象引用，自己定義的庫函數都作為這個對象的靜态函數供外部使用通路；類外一種就是一個類jQuery的內建解決方案，相信介紹我就不必多說了。

這兩種方式各有利弊吧，經過數次糾結還是決定使用靜态方法，好處有幾個

1. 代碼可讀性還稍微高那麼一小點兒，因為相對于類jQuery這樣的寫法還是更好了解一些，友善别人讀代碼

2. 現在大部分網站包括我們公司自己的網站中大部分頁面已經引用了jQuery，在寫一個類似的實際意義不大，而寫一個靜态方法的可以在沒有應用jQuery的頁面上阻隔簡單的拓展

3.  從實用性上考慮，實際上要不是因為有些比較複雜的選擇器浏覽器相容性問題，我幾乎是不使用jQuery的，而平時自己寫一些demo頁面，結構很簡單，根本用不到複雜的選擇器，相反最常用的就是綁定方法等這些小功能，寫個靜态方法類的平時用起來更友善

標明了架構後看看标題，有些難為情，因為下面這兩句就是架構的代碼，這麼簡單都不好意思稱之為架構

庫檔案

在讀jQuery源碼的時候我發現很難讀，裡面各種方法穿插，經常讀到某句的時候，發現其調用了一個内部函數，然後再去找這個内部函數在哪裡，好麻煩，是以在自己寫的庫函數裡面幹脆把公用的内部函數寫到最前面，友善查找。

看過一些書講過jQuery的一個好處就是不會與未來的API沖突，如果對JavaScript原生對象進行拓展很大可能會與未來API沖突，除非把名字起的非常奇怪，這裡就盡量做一下判斷原生的有沒有，并且随時關注人家未來API是什麼樣子，盡量把作用及傳回結果保持一緻，使IE低版本用起來也不會感覺很奇怪。

（後記：最近聽取朋友意見将JavaScript原生對象拓展部分抽取出庫函數，放到了一個extention.js内）

我平時除了選擇器用的最頻繁的大概就是Event處理了（最近在做插件），是以把它放到最前面，DOM拓展、CSS部分希望寫一些對class的處理、對DOM元素移動、添加、删除等處理，Ajax及動畫就是那麼回事兒了，簡單插件部分希望添加像Dialog、Tab、Tree這樣的插件吧

這隻是今天早上拍拍腦袋的初步計劃與設想，有很多缺陷，希望各位多給意見，如果不吝分享自己的就更感激不盡了。

   本文轉自魏瓊東部落格園部落格，原文連結：http://www.cnblogs.com/dolphinX/p/3293501.html，如需轉載請自行聯系原作者