面向對象編程的藝術「設計模式」

編程不只是一門技術，更加是一門藝術。不能只知足於程序運行正確，而要時常思考如何讓代碼更加容易維護，易於擴展和複用。

學習設計模式並不表明你未來會用到這些模式，更重要的意義在於讓你找到「封裝變化」、「對象間鬆散耦合」、「針對接口編程」的感受，從而設計出易維護、易擴展、易複用、靈活性好的程序。

 

面向對象五大原則

封裝、繼承、多態是面向對象的三大特性，但並非說在程序設計中體現出這三大特性就是面向對象，真正的面向對象須要符合下面的五大原則。

單一職責原則（SRP）、開放封閉原則（OCP）、里氏替換原則（LSP）、依賴倒置原則（DIP）、接口隔離原則（ISP）

 

單一職責原則（SRP）

• 單一職責原則，就一個類而言，應該僅有一個引發它變化的緣由。

若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，一個職責的變化可能會削弱或者抑制這個類完成其餘職責的能力。

軟件設計的主要工做，就是發現職責並把那些職責相互分離。若是你可以想到多於一個的動機去改變一個類，那麼這個類就具備多於一個的職責。

 

開放封閉原則（OCP）

• 開放封閉原則，軟件模塊應該能夠擴展，可是不可修改。

「對於擴展是開放的，對於更改是封閉的」，這就是開放封閉原則的精神所在。

開放封閉原則是面向對象設計的核心所在，開發人員應該僅對程序中呈現出頻繁變化的那些部分做出抽象。

然而，對於應用程序中的每一個部分都刻意地進行抽象一樣不是一個好主意。拒毫不成熟的抽象和抽象自己同樣重要。

 

里氏替換原則（LSP）

• 里氏替換原則，子類型必須可以替換掉它們的父類型。

子類經過實現父類接口，可以替代父類的做用，程序的行爲不會發生變化。

只有當子類能夠替換掉父類，軟件單位的功能不受到影響時，父類才能真正被複用，而子類也可以在父類的基礎上增長新的行爲。

 

依賴倒置原則（DIP）

• 高層模塊不該該依賴低層模塊，兩個都應該依賴抽象。
• 抽象不該該依賴細節，細節應該依賴於抽象。

依賴於抽象，就是針對接口編程，不要對實現編程，即程序中全部的依賴關係都是終止於抽象或者接口。

抽象的穩定性決定了系統的穩定性，由於抽象是不變的，依賴於抽象是面向對象設計的精髓，也是依賴倒置原則的核心。

 

接口隔離原則（ISP）

• 接口隔離原則，使用多個專門的接口，而不使用單一的總接口。

一個類對另一個類的依賴應該創建在最小的接口上，而每個接口應該承擔一種相對獨立的角色。

接口應該是內聚的，應該避免「胖」接口。一個類對另一個類的依賴應該創建在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。

 

設計模式簡介

設計模式是一套被反覆使用的、多數人知曉的、通過分類編目的、代碼設計經驗的總結。

設計模式是軟件工程的基石，它使代碼編制真正工程化。天然地使用設計模式，不要濫用用他們。

 

工廠模式

• 工廠模式，定義一個建立對象的接口，讓其子類本身決定實例化哪個工廠類，工廠模式使其建立過程延遲到子類進行。

工做模式適合在須要生成複雜對象的狀況下使用，而當能夠直接實例化建立對象的時候，則無需使用工廠模式。

 

抽象工廠模式

• 抽象工廠模式，提供一個建立一系列相關或相互依賴對象的接口，而無需指定它們具體的類。

抽象工廠模式是圍繞一個超級工廠建立其餘工廠。在抽象工廠模式中，接口是負責建立一個相關對象的工廠，不須要顯式指定它們的類。

 

單例模式

• 單例模式，保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

單例模式讓類自身負責建立它的惟一實例，並提供一個訪問該實例的方法，減小了頻繁建立和銷燬實例的開銷，避免了對資源的多重佔用。

 

建造者模式

• 建造者模式，將一個複雜的構建與其表示相分離，使得一樣的構建過程能夠建立不一樣的表示。

建造者模式主要用於建立一些複雜的對象，這些對象內部構建間的構造順序一般是穩定的，但對象內部的構建一般面臨着複雜的變化。

 

原型模式

• 原型模式，用原型實例指定建立對象的種類，而且經過拷貝這些原型建立新的對象。

原型模式其實就是在初始化信息不發生變化的狀況下，克隆一個已實例化的對象。若是字段是值類型的，則對該字段逐位複製，若是字段是引用類型，則複製引用但不復制引用的對象。

 

適配器模式

• 適配器模式，將一個類的接口轉換成合適的接口，使得本來接口不兼容的類能夠一塊兒工做。

適配器模式主要應用於但願複用一些現存的類，可是接口又與複用環境要求不一致的狀況。適配器繼承或依賴已有的對象，實現想要的目標接口。

 

橋接模式

• 橋接模式，將抽象部分與它的實現部分分離，使它們均可以獨立變化。

橋接模式涉及到一個做爲橋接的接口，使得實體類的功能獨立於接口實現類。橋接是用於把抽象化與實現化解耦，使得兩者能夠獨立變化。

 

組合模式

• 組合模式，依據樹形結構來組合對象，用來表示部分以及總體層次。組合模式使得用戶對單個對象和組合對象的使用具備一致性。

基本對象能夠被組合成更復雜的組合對象，而這個組合對象又能夠被組合，這樣不斷地遞歸下去，任何用到基本對象的地方均可以使用組合對象了。

 

裝飾模式

• 裝飾模式，動態的給一個對象添加一些額外的職責，就增長功能來講，裝飾模式比生成子類更爲靈活。

裝飾模式是爲已有功能動態地添加更多功能的一種方式，它把每一個要裝飾的功能放在單獨的類中，從而有效地把類的核心職責和裝飾功能區分開。

 

外觀模式

• 外觀模式，隱藏系統的複雜性，並向客戶端提供了一個客戶端能夠訪問系統的接口。

外觀模式定義了一個高層接口，下降訪問複雜系統的內部子系統時的複雜度，使得這一子系統更加容易使用。

 

享元模式

• 享元模式，運用共享技術嘗試重用現有的同類對象，若是未找到匹配的對象，則建立新對象。

在有大量對象時，有可能會形成內存溢出，咱們把其中共同的部分抽象出來，若是有相同的業務請求，直接返回在內存中已有的對象，避免從新建立。

 

代理模式

• 代理模式，爲其餘對象提供一種代理以控制對這個對象的訪問。

遠程代理，爲一個對象在不一樣的地址空間提供局部表明。虛擬代理，根據須要建立開銷很大的對象。安全代理，用來控制真實對象訪問時的權限。

 

職責鏈模式

• 職責鏈模式，使多個對象都有機會處理請求，從而避免請求的發送者和接收者之間的耦合關係。

避免請求發送者與接收者耦合在一塊兒，讓多個對象都有可能接收請求，將這些對象鏈接成一條鏈，而且沿着這條鏈傳遞請求，直到有對象處理它爲止。

 

命令模式

• 命令模式，將一個請求封裝爲一個對象，從而使你能夠用不一樣的請求對客戶進行參數化。

請求以命令的形式傳遞給調用對象，調用對象尋找能夠處理該命令的合適的對象，並把該命令傳給相應的對象，該對象執行命令。

 

解釋器模式

• 解釋器模式，給定一個語言，定義它的文法表示，並定義一個解釋器，這個解釋器使用該標識來解釋語言中的句子。

若是一種特定類型的問題發生的頻率足夠高，那麼可能就值得將該問題的各個實例表述爲一個簡單語言中的句子。這樣就能夠構建一個解釋器，該解釋器經過解釋這些句子來解決該問題。

 

迭代器模式

• 迭代器模式，提供一種方法順序訪問一個聚合對象中的各個元素，而又不暴露該對象的內部表示。

迭代器模式就是分離了集合對象的遍歷行爲，抽象出一個迭代器類來負責，這樣既能夠作到不暴露集合的內部結構，又可讓外部代碼透明地訪問集合內部的數據。

 

中介者模式

• 中介者模式，用來下降多個對象和類之間的通訊複雜性。通常用於一組對象已經定義良好可是通訊複雜的場合。

中介者模式用一箇中介對象來封裝一系列的對象交互，中介者使各對象不須要顯式地相互引用，從而使其耦合鬆散，並且能夠獨立地改變它們之間的交互。

 

備忘錄模式

• 備忘錄模式，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，以便在適當的時候恢復對象。

所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內部狀態，並在該對象以外保存這個狀態，這樣能夠在之後將對象恢復到原先保存的狀態。

 

觀察者模式

• 觀察者模式，定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。

觀察者模式所作的工做其實就是在解除耦合。讓耦合的雙方都依賴於抽象，而不是依賴於具體。從而使得各自的變化都不會影響另外一邊的變化。

 

狀態模式

• 狀態模式，當一個對象的內在狀態改變時容許改變其行爲，這個對象看起來像是改變了其類。

狀態模式主要解決的是當控制一個對象狀態轉換的條件表達式過於複雜時的狀況。把狀態的判斷邏輯轉移到表示不一樣狀態的一系列類當中，能夠把複雜的判斷邏輯簡化。

 

策略模式

• 策略模式，定義了算法家族，分別封裝起來，讓它們之間能夠互相替換，減小了算法類之間的耦合。

策略模式是一種定義一系列算法的方法，它能夠以相同的方式調用全部的算法，減小了各類算法類與使用算法類之間的耦合。

 

模板方法模式

• 模板方法模式，定義一個操做中的算法骨架，而將一些步驟延遲到子類中。

模板方法模式經過把不變的行爲搬移到超類，使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。

 

訪問者模式

• 訪問者模式，主要將數據結構與數據操做分離，解決穩定的數據結構和易變操做的耦合問題。

訪問者模式適用於數據結構相對穩定的系統，它把數據結構和做用於結構上的操做之間的耦合解脫開，使得操做集合能夠相對自由地演化。