《JavaScript設計模式》初次筆記
前言
設計模式一直久仰大名，但是沒有去花時間去了解，於是今天特意花時間去看《JavaScript設計模式》（2013年6月出版）和w3cschool上的設計模式。然後做了一些筆記。
以《JavaScript設計模式》爲目錄，以w3cschool上的設計模式爲補充。
講的內容有三：設計模式、JavaScript設計模式、其他（模塊化的JavaScript設計模式、jQuery設計模式、jQuery插件設計模式）。
學習目的：嘗試性地瞭解JavaScript設計模式，方便看源碼。
閱讀感受，《JavaScript設計模式》講除開頭部分其他部分太官方和書面了，一點也不利於理解。連打個比方都不會。而且順序也不合理，至少我沒get到。不過w3cschool上的設計模式超出我的預期，總結得比《JavaScript設計模式》好。不過《JavaScript設計模式》的目錄我還是比較能接受的。
文章目錄
設計模式
設計模式是解決軟件設計中常見問題的可複用方案。不管是探索任何編程語言，這都是通用的。推薦設計模式的原因有二，一是設計模式是前人總結的經驗，藉助這些經驗，我們可以解決棘手的問題和優化代碼。二是設計模式還是我們用來描述解決方案的常用詞彙，我們用設計模式的詞彙去描述解決方案的時候會比描述語法更簡單。
前置知識：JavaScript、閉包、原型繼承等。
設計模式的原由
設計模式來源於土木工程師亞歷山大的早期作品，總結他解決設計問題方面的經驗，在1977年發表了《建築設計語言》的文章。
之後軟件工程師把亞歷山大編寫的建築設計原則納入設計模式的文檔，成爲開發人員改進編程技巧的語言。在1995年GoF出版《設計模式：可複用面向對象軟件的基礎》。
GoF發表的著作大大推進了設計模式概念在編程領域的發展，它描述了許多開發技術和誤區，並列舉了23面向對象設計中最常用的經典設計模式。
模式
模式是一種可複用的解決方案，設計模式有三大好處：模式是已經驗證的解決方案，模式很容易被複用，模式複用表達力。
學習設計模式是需要先了解原始模型proto-pattern。原始模型是一種沒有經過模式測試的設計模式，是值得在社區分享的特殊解決方案，不過產生時間短，還沒有機會對其進行嚴格的審查。（設計模式需要經過嚴格的審查）
模式具有三法則：適合、實用、適用；
設計模式的結構、編寫設計模式文件不細敘述了。（畢竟目前我只是想用模式，還不想去設計。）
反模式：如果認爲模式代表最佳實踐，那麼反模式就代表教訓。反模式是一種值得記錄的不良設計。
設計模式類別
23種設計模式：大體分爲三類
創建型模式，專注於處理對象創建機制。共五種：Prototype（原始模型模式），Singleton（單例模式），Factory（工廠模式）， Builder（建造模式）， Factory Method（工廠方法模式）。
結構型模式，與對象組合有關，用於找出在不同對象之間建立關係的簡單方法。共七種：Facade（門面模式），Adapter（適配器模式），Decorator（裝飾模式）， Flyweight（享元模式）， Proxy（代理模式）， Bridge（橋樑模式）， Composite（合成模式）。
行爲型模式，專注於改善或簡化系統中不同對象之間的通信。共十一種： Visitor（訪問者模式），Iterator（迭代子模式）， Mediator（調停者模式），Observer（觀察者模式），Command（命令模式）， Interpreter（解釋器模式）， Memento（備忘錄模式）， State（狀態模式）， Strategy（策略模式），Template Method（模板方法模式）， Chain Of Responsibleity（責任鏈模式）
JavaScript設計模式
創建型模式，四種。Constructor（構造器）模式、Prototype（原始模型模式），Singleton（單例模式），Factory（工廠模式）
結構型模式，三種。Facade（外觀模式），Decorator（裝飾模式）， Flyweight（享元模式）。
行爲型模式，三種。Mediator（中介者模式），Observer（觀察者模式）、Command（命令模式）。
組件的模式，三種。Module、Revealing Module、Mixin。
MV模式，三種。MVC、MVP、MVVM
補充：後端架構模式，六種。業務代表模式、組合實體模式、數據訪問對象模式、前端控制器模式、攔截過濾器模式、服務定位模式。
我覺得設計模式應該從定義、優點、缺點、適用場景這四個角度來講。書本上的講法太死板了，讀得迷迷糊糊。（用途和實現我就沒細說了）
創建型模式
Prototype模式：基於現有對象模板，通過克隆方式創建對象的模式。
優點：沒看懂；性能提高，逃避構造函數的約束
缺點：沒看懂；逃避構造函數的約束。
適用場景：資源優化場景；類初始化需要消耗許多資源，new產生一個對象需要非常繁瑣的數據準備；
在實際項目中，原型模式很少單獨出現，一般和工廠模式一起出現，通過clone的方法創建一個對象，然後由工廠方法提供給調用者。
與通過對一個類進行實例化來構造新對象不同的是，原型模式是通過拷貝一個現有對象生成新對象的。
Factory模式：可以在不對客戶端暴露創建邏輯的情況下創建對象，通過一個共同接口來指向新創建的對象。
優點：不需要管對象是怎麼構成的，只需要通過接口便可創建出對象。
缺點：每次增加一個產品時，都需要增加一個具體類和對象實現工廠，使得系統中的類的個數倍增，增加了複雜性。
適用場景：spring就用到工廠設計模式。
Singleton模式：類的實例化次數只能一次。
優點：在內存中只要一個實例，減少內存開銷，避免資源多重佔用；
缺點：沒有接口、不能繼承，一個類只需要關係內部邏輯，不用關係怎麼實例。
適用場景：一個全局使用的類頻繁地創建與銷燬。
Constructor模式：奇奇怪怪的模式，在23中設計模式中就沒提到，應該是JavaScript所特有的。書面解釋是在內存已分配給對象的情況下，初始化新創建對象的特殊方法。mmp，什麼意思。意淫式描述，就自己懂，別人都看不懂。
在這裏優缺點我就不講了，不懂。但是一些相關的說明可以寫。
JavaScript不支持類的概念，但支持與對象一起用的constructor函數。通過在構造器前面加new關鍵字，就可以實例化一個新對象。
在構造器內，關鍵字this引用新創建的對象。
結構式模式
Facade模式：隱藏系統的複雜性，並向客戶端提供一個客戶端可以訪問系統的接口。提供可用性。
優點：易於使用，實現該模式佔用空間小。
缺點：改東西麻煩，繼承重寫都不合適。
適用場景：客戶端不需要知道系統內部的複雜聯繫，整個系統只需提供一個"接待員"即可。去醫院看病，可能要去掛號、門診、劃價、取藥，讓患者或患者家屬覺得很複雜，如果有提供接待人員，只讓接待人員來處理，就很方便。
Decorator模式：允許向一個現有的對象添加新的功能，同時又不改變其結構。它是作爲現有的類的一個包裝。
適用場景：擴展一個類的功能；動態增加功能，動態撤銷。
Flyweight模式：重用現有的同類對象。用於減少創建對象的數量，以減少內存佔用和提高性能。
適用場景：用於優化重複、緩慢及數據共享效率低的代碼。
行爲式模式
Command模式：一種數據驅動的設計模式。將一個請求封裝成一個對象，從而使得開發者可以用不同的請求對客戶進行參數化。
適用場景：GUI；CMD；
Observer模式：當一個對象被修改時，自動通知它的依賴對象。
懂好像是懂了，但優缺點是啥呀。
Mediator模式：用一箇中介對象來封裝一系列的對象交互，中介者不需要顯式地互相引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互。
適用場景：MVC框架，C就是M和V的中介者。
模塊化的模式
Module模式：一種爲類提供私有和公有封裝的方法，在JavaScript中用於模擬類，使得一個單獨的對象擁有公有/私有方法和變量，從而屏蔽來自全局作用域的特殊部分。
Module模式使用閉包封裝“私有”狀態和組織。它提供了一種包裝混合公有/私有方法和變量的方式，防止其泄漏至全局作用域，並與別的開發人員的接口衝突。
優點：封裝不變部分，擴展可變部分；提供公共代碼，便於維護。
缺點：每一個不同的實現都需要一個子類來實現，導致類的個數增加。
Revealing Module模式：對Module模式的改進，能在私有範圍內簡單定義所有的函數和變量，並返回一個匿名對象，它擁有指向私有函數的指針。
Mixin模式：在JavaScript中，繼承Mixin看作爲一種通過擴展收集功能的方式。使對象通過較低複雜性借用功能，非常適合JavaScript的對象原型。
MV架構模式
MVC模式：架構設計模式，通過關注點分離改進應用程序的組織。它強調業務數據Model與視圖View分離，第三個組件Controller管理邏輯和用戶輸入。
在1979年設計出來，在1995年被深入闡述。
MVC實際上是Observer模式、Strategy模式和Composite模式的變體。它
是實現方式中也可以使用Factory模式和Template模式。
MVP模式：MVP是MVC的一種衍生模式，1990年被創造出來。跟適合Web框架。Presenter表示表示器，是一個包含用於View的用戶界面業務邏輯的組件。
MVVM模式：一種基於MVC和MVP的架構模式，利用聲明式數據綁定來實現把View工作從其他層分離。有助於同一個代碼庫中UI和開發工作的同時進行。2005年被髮布。
優點：並行開發更容易；減少代碼背後所需業務邏輯量；單元測試更容易；
缺點：對於簡單UI，有些大材小用；數據綁定是聲明式的，比命令式代碼更難調試；在大型應用程序中，預先設計大量VM可能很困難。
補充
下面這六個模式，我以前用過，沒想到這也是模式。
業務代表模式：用於對錶示層和業務層的解耦；
數據訪問對象模式：POJO、接口、接口實現類
前端控制器模式：控制器、調度器、視圖
組合實體模式、攔截過濾器模式、服務定位器模式：略
其他
模塊化的JavaScript設計模式
好煩，這本書講的這部分內容，沒法記筆記，也許我層次沒達到，反正我是沒看懂的。
AMD和CommonJS模塊。
我打算參考《前端技術架構與工程》的第四章。在這裏還是以設計模式爲主，剩下的部分暫時不作過多深入。
jQuery中的設計模式
可惜這本書是2013年出版的，那時候流行的是jQuery，如果晚幾年可能就會介紹React的設計模式。不過這裏的 jQuery也可以借鑑，可是這裏也過於書面了。
Composite模式、Adapter模式、Facade模式、Observer模式、Iterator模式、延遲初始化、Proxy模式、Builder模式；
jQuery插件設計模式
模式、Lightweight Start模式、完整的widget factory、嵌套命名空間插件模式、自定義事件插件模式（使用widget factory）、使用DOM to Object Bridge模式的原型繼承、jQuery UI Widget Factory Bridge模式等；
全局選項和單詞調用可重寫選項、高可配和高可變的插件模式、插件超越模式；
命名空間模式、基礎、高級；
總結
今天算是順了一遍設計模式。《JavaScript設計模式》的前面一部分還好，後面的部分簡直扎心，領悟不到，還好有w3cschool，可以看懂一些設計模式。不過還是很有幫助的。也算是揭開了設計模式的面紗，之前只是簡單瞭解。
之前的23種設計模式我是聽說過，創建型模式、結構型模式、行爲模式有過大致瞭解。這次看了這本書和w3cschool，還補充了組件化模式、框架模式、數據訪問模式。突然發現原來之前也用過模式，只是沒像現在一樣去定義。
我覺得學習設計模式最重要的是理解思想，只要領悟了宗旨，才能萬變不離其宗。
設計模式的思想
我閱讀之後的感受是，設計模式就是一種思想，提高可複用性和維護性，使開發高效，開發成本降低，危險降低。
博客園上的設計模式的理論思想 講的不錯。
同時學習設計模式必須學以致用，如果不用的話，不用深入。
設計模式的內容
| 範圍 | 創建型 | 結構型 | 行爲型 |
|---|---|---|---|
| 類 | Factory Method（工廠方法） | Adapter(類) （適配器） | Interpreter（解釋器） Template Method（模版方法） |
| 對象 | Abstract Factory（抽象工廠） Builder（建造者） Prototype（原型） Singleton（單例） |
Bridge（橋接） Composite（組合） Decorator（裝飾者） Façade（外觀） Flyweight（享元） Proxy（代理） |
Chain of Responsibility（職責鏈） Command（命令） Iterator（迭代器） Mediator（中介者） Memento（備忘錄） Observer（觀察者） State（狀體） Strategy（策略） Visitor（訪問者） |
在CSDN上看到的這篇創建型模式、結構型模式和行爲型模式之間的關係很不錯。
1、創建型模式
軟件設計的過程是循序漸進的，一步一步來的。在軟件設計中對象的創建和對象的使用是分開的，因爲對象的創建會消耗掉系統的很多資源，所以單獨對對象的創建進行研究，從而能夠高效地創建對象就是創建型模式要探討的問題。這裏就提供了多種創建型模式進行選擇使用。
2、結構型模式
在解決了對象的創建問題之後，對象的組成以及對象之間的依賴關係就成了開發人員關注的焦點，因爲如何設計對象的結構、繼承和依賴關係會影響到後續程序的維護性、代碼的健壯性、耦合性等。所以也有多種結構型模式可供開發人員選擇使用。
3、行爲型模式
在對象的結構和對象的創建問題都解決了之後，就剩下對象的行爲問題了，如果對象的行爲設計的好，那麼對象的行爲就會更清晰，它們之間的協作效率就會提高。
此外組件化、框架模塊、架構模塊都是根據設計模式使開發可複用和可維護。一切爲了提高開發效率，便於維護。
以上就是我的初次筆記，設計模式沒講得通俗易懂，不過以後不斷學習不斷理解，再寫自己的心得。
更新地址：GitHub