【譯】《學習JavaScript設計模式》（二）

原書連接Learning JavaScript Design Patterns
水平有限不少地方不通順，錯翻漏翻歡迎交流。

模式測試，原生模式&約法三章

記住並非全部的算法啊，最佳實踐啊，解決方案啊什麼的均可以被稱爲一個完整的模式的。極可能它就缺了點什麼，而社區裏的那些傢伙就喜歡揪着這小辮子不放，直到它通過千錘百煉出關。即便一個模式已經知足了全部模式標準，還須要通過時不時的合適的測試審查的調教才能成長爲一個真正的男人，哦不，模式。

回頭看看Alexander說過的，一個模式既是一個過程，也是一個完整的事物。

學習模式設計的過程當中，咱們遇到"原生模式"這玩意兒也不是啥大驚小怪的事。這是個啥？Well，一個還沒經過模式測試畢業考試的模式一般就叫原生模式。原生模式的主人把它造出來以後拿到社區裏讓你們一塊兒玩兒，可是因爲年紀過小了，還沒被從裏到外翻雲覆雨地玩。

或者把原生模式生下來的人對這一系列的測試根本沒啥興趣，給脖子上掛個出生證實就讓它自生自滅去了。咱們一般把這個出生證實叫作"patlets"。

也不怪他們，給這些模式寫個完整的文檔確實讓人萌生退意。回頭看看早期的一些工做，知足下列條件的模式才能成爲好的模式：

• 解決了一個特定的問題： 我寫了一個模式出來，一歲出頭鵝蛋臉眉眼帶笑鼻子挺直嘴角上揚脣紅齒白，可她只能看啥事都作不了有啥用啊。能作事兒，這是一個好的模式最關鍵的特徵。

• 高手都是會隱藏的： 咱們知道解決問題的技術一般都是從一些出名的基本原理衍生出來的。最好的設計模式一般不直接給出問題的答案，這被人認爲是解決困難問題的必要步驟。高手嘛，教的都不是形，而是意。

• 給出的概念必定要是被證明過的： 設計模式要給他們的功能提供專業鑑定書，沒有專業鑑定書的都是野路子上不了檯面。只有勇士和走投無路的人才敢用那些沒來歷的野生模式。

• 必須闡釋清楚代碼關係： 有些狀況下，模式只是解釋了一些模塊。不少已經成型的模式可能也只是吊樣，可是官方定義的模式必須闡釋更底層的系統關係結構並解釋清楚代碼之間的關係。

看到這兒你或許以爲本身不去學習那些不太規則的原生模式沒什麼關係吧。可不是這樣。不少原生模式也是依壁雕鑿，固然不是說全部的原生模式都樣兒，可是確定有很多很好的原生模式，使用我上面告訴你的方法來自行判斷吧。

爲了保持模式的可重用性，咱們要約法三章，並將三規則核心價值觀時刻牢記心中（別問我這仨有啥區別，核心價值觀記住就好了）：

1. 對目標的可用性： 模式是怎麼被認爲是成功的？

2. 有用性： 爲何這個模式被認爲是成功的？

3. 適用性： 這是一個由於有普遍適用性因此能成爲一個模式的設計嗎？若是是，好好寫文檔吧。重寫或者定義模式的時候，記住上面三點是很是重要的。