This content is over 10 years old. It may be obsolete and may not reflect the current opinion of the author.

JavaScript 是個瘋狂的語言，語言本身非常隨便自由，從不試圖引導程式設計師遵守特定的模式。我參與的 Gaia Project 無論是商業需求或是架構上也是很瘋狂的；試圖用 Web 湊出一個手機介面以及功能，但同時間新需求又來的又快又急。在一開始的幾年，我們一直沒有機會慢下腳步，想想每個人喜歡用的 module pattern、singleton pattern 等等是不是符合未來的需求。但最近一年以來，幾位同事終於慢慢的意識到，使用 JavaScript 一開始發明時提供的 constructor function pattern，才是最安全，符合最多 use case 的作法。以下整理我認為的幾個關鍵的優點，供各位參考：

優點 1：沒有封裝（encapsulation）

許多人認為沒有封裝，曝露實作細節是一個缺點，但我認為不做任何封裝的益處比壞處更多。直覺上大家會認為 JavaScript 元件需要封裝，是因為大家習慣使用黑盒子式的 library （例如 jQuery）。jQuery 作為一個灑到外面給大眾使用的函式庫，隱藏細節來保留未來升級的空間是有必要的。但在自己或是協作專案中，藉由封裝來防禦這樣的「使用者」是沒有必要的——大不了就是開一張票給同事請他改掉。若有試著閱讀過 jQuery 程式碼和 build system 的朋友，也會發現，jQuery 專案本身各 function 在它內部的 scope 也是攤平，獨立測試的。與其用封裝作防禦，不如用完整的測試來定義 public method 的行為；這就要談下一個優點。

優點 2：可測試性

Test-Driven Development 似乎非常流行，但我們得承認不是所有的元件都有清晰的需求與憑空定義的 interface，可以先開完會、冥想一下，然後寫完測試，凍結測試再開工。元件的形狀與介面勢必是個隨著需求或是撰寫過程發現的 edge case 而演化出來的。在 Gaia 開發的歷史一開始是不要求單元測試（unit test）的；許多使用封裝模式設計的元件隨著需求慢慢的長大，長到最後發現無法切出可測試的獨立單元。如果使用 constructor function，就可以保證永遠找的到可測試的單元：「單元」可以是掛在 prototype 上的一個方法，也可以直接測試一個 instance。我個人的習慣是測試 instance，原因如下。

優點 3：各 instance 與 prototype 預設是分離的

Gaia 開發的歷史，遭遇的另一個問題是，許多元件都被設計成在環境中只會被使用一次。這樣的元件，勢必沒有可供單元測試項目獨立使用的 instance。當時最後使用的醜陋解法是確定測試時會改變的 state property，在每個測試的 teardown() 將它重設，但更絕望的是有些元件的 state 根本就封裝在自己的 scope 內，這就完全沒救而且嚴重的傷害的我們的測試涵蓋率。分析哪個 property 是 state 也一個手動而且容易出錯的過程。若當初使用 constructor function，每個 instance 就可以是用完即丟的測試單元，另外，console.log(instance) （或是 JSON.stringify(instance)）可以直接印出 instance 上面的所有被設定的 property，跟它的 prototype 上的 property 或是 method 完全切開。

但在這邊要注意的是每個 instance 不會真的用完即丟，尤其是和 DOM API 有互動的元件。我們最後定義了一組通用的 method 名稱，要求元件都要有 stop() method 讓 instance 把自己從 DOM 上分離下來。

優點 4：「天然的感覺」

懂 JavaScript 的 prototype inheritance 老實說就跟日文的五段動詞一樣，大家學的時候都知道好像要學到那邊才算學會了什麼，但是在那之前總是卡一堆人（苦笑）。Prototype inheritance（或是簡單的，constructor 與 instance 的關係）在學習曲線上的問題是看起來沒有實際的例子可以參考，object 內部的繼承關聯也沒有被 JavaScript Engine 暴露出來。但這件事情在 ECMAScript 5 之後已經有了改善；我們現在有 Object.create()、Object.getPrototypeOf()，還有原本就有的 constructor 屬性與 instanceof 運算子。要找實際的例子就更令人例外了：其實大家每天使用的 DOM API 都只是某個 constructor 的 instance，本身沒有 method，執行的時候其實是執行它的 prototype 上的 method；不相信的話，打開 console 看看 Object.getPrototypeOf(navigator) 是回傳哪個 object，或是 navigator.constructor、navigator.constructor.prototype 是什麼。

（玩完之後你會發現 Object.getPrototypeOf(navigator) 跟 navigator.constructor.prototype 都會指到一個名為 NavigatorPrototype 的 object，navigator.constructor 會是一個 constructor function。不過執行它不會得到新的 navigator object 而是會 throw。你也不能 new window.constructor() 或是 new Window() 得到另一個 window object。）

總之，無論元件們最後是要從相依性來層層呼叫 new 建立出來，還是偽裝成 DOM API 掛在 window 或是 navigator 底下，實際運作的 object 都應該是 instance 而不是 object dict，因為你所仰賴的 DOM API 就是這樣實作的。從這裡出發也更容易看出與操作 this 關鍵字所指向的 object，進而寫出乾淨的程式碼（例如實作 EventListener interface）。這是我所謂「天然的感覺」。

結語

以上大略是我們選擇 constructor function 建構元件的理由。當然，沒有任何技術分享或是 framework 是適用所有專案的，請保持求真的精神，尋找您自己的真理。

P.S. 圖片跟這篇文章真的沒有關係。