原來設計模式是這樣的

設計模式第一遍用快速閱讀的方式結束了。沒有去敲執行個體，隻是想着先把整本書從頭到尾讀完一遍。讀完後，終于揭開了設計模式的神秘面紗。本篇部落格還是選擇以問題的角度入手，像學習uml一樣，多問自己幾個什麼，進而得以把握其全局。

一.什麼是設計模式？

看完書，我覺得設計模式就是在程式設計過程中根據不同的情況去選擇運用固定的一系列模式，每次大鳥給小菜講模式，都是根據實際發生的事，自然而然地引出該用什麼模式了。全部加起來，他們倆講了很多很多，這也将在後面總結整理一下。另外，給大家也提供個百科上的說法看看：設計模式（design pattern）是一套被反複使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。

二.為什麼有設計模式？

這個問題的答案很簡單，回想書中，每次小菜編寫完程式，大鳥總不是很滿意的，有時候覺得太複雜；有時候又覺得程式太死闆，不能靈活變通；有時候又覺得要是修改一下代碼，将是很大的一項工程，有種牽一發而動全身的感覺......總之，歸結起來，大鳥覺得小菜的編寫的程式根本不符合軟體工程思想的目标，是以，就教給小菜各種設計模式，進而達到“高内聚，低耦合”，可修改、可擴充等等。百科上是這麼說的：為了可重用代碼、讓代碼更容易被他人了解、保證代碼可靠性。

毫無疑問，設計模式于己于他人于系統都是多赢的；設計模式使代碼編制真正工程化；設計模式是軟體工程的基石脈絡，如同大廈的結構一樣。

三.設計模式有哪些？

翻開書的目錄數數，應該總共包含23種。這23種并不都是孤立的，下面我們就将它們分類整理整理。

設計模式分為三種類型，分别為

（一）建立型模式，其中包括：

● 單例模式（singleton）：保證一個類僅有一個執行個體，并提供一個通路它的全局通路點。【計劃生育——執行個體化工具箱】

● 抽象工廠模式（abstract factory）：提供一個建立一系列相關或互相依賴對象的接口，而無需指定它們具體的類。【換不換db——資料通路程式】

● 建造者模式（builder）：将一個複雜對象的建構與它的表示分離，使得同樣的建構過程可以建立不同的表示。【好菜味不同——構造人】

● 工廠模式（factory method）：定義一個用于建立對象的接口，讓子類決定執行個體化哪一個類。【雷鋒——加減乘除運算】

● 原型模式（prototype）：用原型執行個體指定建立對象的種類，并且通過拷貝這些原型建立新的對象。【履歷影印——履歷複制】

（二）結構型模式，其中包括：

● 擴充卡模式（adapter）：将一個類的接口轉換成客戶希望的另外一個接口。其使得原本由于接口不相容而不能一起工作的類可以一起工作。【nba需要翻譯——籃球翻譯】

● 橋接模式（bridge）：将抽象部分與它的實作部分分離，使它們都可以獨立地變化。【手機軟體統一——手機品牌與應用】

● 裝飾模式（decorator）：動态地給一個對象添加一些額外的職責，就增加功能來說，比生成子類更為靈活。【穿什麼——人服飾搭配】

● 組合模式（composite）：将對象組合成樹形結構以表示部分-整體層次結構。其使使用者對單個群組合對象的使用具有一緻性。【分公司——公司管理系統】

● 外觀模式（facade）：為子系統中的一組接口提供一個一緻的界面，其定義了一個高層接口，使得子系統更加容易使用。【股票虧錢——投資基金】

● 享元模式（flyweight）：運用共享技術有效地支援大量細粒度的對象。【項目多别傻做——網站共享代碼】

● 代理模式（proxy）：為其他對象提供一種代理以控制對這個對象的通路。【為别人做嫁衣——送禮物】

（三）行為型模式，其中包括：

● 模闆方法模式（templatemethod）：定義一個操作中的算法的骨架，而将一些步驟延遲到子類中。其使得子類可以不改變算法結構即可重定義該算法的某些特定步驟。【考題抄錯——試題】

● 指令模式（command）：将一個請求封裝為一個對象，進而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支援可撤銷的操作。【烤羊肉串——點餐】

● 疊代器模式（iterator）：提供一種方法順序通路一個聚合對象中各個元素，而又不暴露該對象的内部表示。【想走先買票——上車買票】

● 觀察者模式（publish/subscribe）：定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀态發生變化時，會通知所有觀察者對象，使它們能夠自動更新自己。【老闆回來——秘書通知同僚】

● 中介者模式（mediator）：用一個中介對象封裝一系列的對象互動。中介者使各對象不需要顯式地互相引用，進而使其耦合松散，而且可以獨立改變它們之間的互動。【世界**——安理會做中介】

● 備忘錄模式（memento）：在不破壞封裝性的前提下，捕獲一個對象的内部狀态，并在該對象之外儲存這個狀态。這樣以後就可将該對象恢複到原先儲存的狀态。【回到從前——遊戲進度儲存】

● 解釋器模式（interpreter）：給定一個語言，定義它的文法的一種表示，并定義一個解釋器，用來表示解釋語言中的句子。【不懂老闆的心——音樂解釋器】

● 狀态模式（state）：當一個對象的内在狀态改變時允許改變其行為，這個對象看起來像是改變了其類。【無盡加班——工作狀态】

● 政策模式（strategy）：定義了算法家族，分别封裝起來，讓它們之間可以互相替換，此模式讓算法的變化，不會影響到使用算法的客戶。【商場促銷——商場收銀】

● 職責鍊模式（chain of responsibility）：使多個對象都有機會處理請求，進而避免請求的發送者和接收者之間的耦合關系。将這個對象連成一條鍊，并沿着這條鍊傳遞該請求，知道有一個對象處理它為止。【加薪要老總批——加薪】

● 通路者模式（visitor）：表示一個作用于某對象結構中的各元素的操作。它可以使再不改變各元素的類的前提下定義作用于這些元素的新操作。【男人和女人——人及其狀态】

四.設計模式遵循哪些原則？

● 單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。

● 依賴倒轉原則：高層子產品不應該依賴低層子產品，兩個都應該依賴抽象。抽象不應該依賴細節。細節應該依賴抽象。

● 迪米特法則：也叫最少知識原則，是指如果兩個類不必彼此直接通信，那麼這兩個類就不應該發生直接的互相作用。如果其中一個類需要調用另一個類的某一個方法的話，可

以通過第三者轉發這個調用。

● 開放-封閉原則：是指軟體實體（類、子產品、函數等等）應該可以擴充，但是不可修改。

● 裡氏代換原則：子類型必須能夠替換掉它們的父類型。

五.學習心得

第一遍的學習看上去僅僅是知識點的羅列，但個人感覺這還是很有必要将其總結在一起的，這樣也有助于下一階段的深入學習。對于第一遍學習中，有不少難題。最開始的一天隻看了第一章，而第二天開始看書的時候在第一章又停留了很久。這時候，想着不能這樣下去，要不然一本書也不知道要看到何時才能結束。是以，還是依照老師快速閱讀的方法，終于在三天内結束了第一遍。有了第一遍這樣的一個全局，接下來第二遍的任務也很清楚了，就是一個個去揭開它們一層層的面紗。各個執行個體也需要落到實處了。