設計模式概述

簡介

設計模式（Design pattern）是在開發過程當中面臨同類軟件工程設計問題的通用解決方案，是軟件開發的最佳實踐。

設計模式的本質是提升軟件的維護性，通用性，擴展性，下降軟件的複雜度。

目的

設計模式給與程序更好的：

1. 代碼重用性（相同功能的代碼，不用屢次編寫）
2. 可讀性 （編程規範性，便於其餘程序員的閱讀和理解）
3. 可擴展性 （方便增長新的功能）
4. 可靠性 （新增的功能對原來的功能沒有影響）
5. 高內聚，低耦合

七大原則

設計模式的七大原則爲：

1. 單一職責原則
2. 接口隔離原則
3. 依賴倒轉原則
4. 里氏替換原則
5. 開閉原則
6. 迪米特法則
7. 合成複用法則

單一職責原則

對類來講，一個類應該只負責一項職責。

若是類T負責兩個不一樣的職責a,b。考慮到職責a變更時可能會形成職責b出錯，應該將類T分解爲T1,T2, 分別單獨負責職責a和職責b。

注意事項

1. 下降類的複雜度，一個類只負責一項職責
2. 提升類的可讀性，可維護性
3. 下降變動引發的風險
4. 一般狀況下，應該遵照單一職責原則。只有邏輯足夠簡單，才能夠在代碼級違反此原則；當類中方法足夠少，能夠在方法級別保持此原則

接口隔離原則

客戶端不該該依賴它不須要的接口，即一個類對另外一個類的依賴應該創建在最小的接口上。

假設類T經過接口I（有方法a,b,c）依賴於V,即V implments I, T use V, 而T中只須要用到I中的部分方法（如a,b）, 那麼應該細化I, 把I分紅I1(a,b), I2(c)，V實現必要的I1便可

依賴倒轉原則

依賴倒轉原則（Dependence Inversion Principle）是指：

1. 高層模塊不該該依賴底層模塊，兩者都應該依賴其抽象
2. 抽象不該該依賴細節，細節應該依賴抽象
3. 依賴倒轉（倒置）的中心思想是面向接口編程
4. 設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建的架構比以細節爲基礎搭建的架構要穩定的多
5. 使用接口或抽象類的目的是制定好規範，而不涉及任何具體的操做，把展示細節的任務交給它們的實現類去完成

依賴關係傳遞的三種方式

1. 接口傳遞
2. 構造方法傳遞
3. setter方式傳遞

注意事項

1. 底層模塊儘可能都要有抽象類或接口，或二者都有，程序穩定性更好
2. 變量的聲明類型儘可能是抽象類或接口。如此，咱們的變量引用和實際對象之間，就存在一個緩衝層，有利於程序擴展和優化
3. 繼承時遵循里氏替換原則

里氏替換原則

對OO中繼承性的思考

1. 繼承有這樣一層含義：凡是父類中已實現好的方法，其實是規範和契約。雖然它不強制要求全部子類必須遵循這些契約，可是若是子類對這些已實現方法任意修改，就會對整個繼承體系形成破壞
2. 繼承在給程序設計帶來便利的同時，也帶來了弊端。如給程序帶來侵入性，程序的可移植性下降，增長對象間的耦合性。若是一個類被其餘類繼承，當這個類須要修改時，必須考慮到全部子類；且父類修改後，全部涉及到子類的功能都有可能產生故障
3. 那麼，在編程中，如何正確使用繼承呢 ===> 里氏替換原則

介紹

1. 對於類型爲T1的對象o1，有類型爲T2的對象o2，使得以T1定義的程序P在全部的對象o1都換成o2時，程序P的行爲不變，那麼T2是T1的子類型。即，全部引用基類的地方都能透明的使用其子類對象
2. 在使用繼承時，遵循里氏替換原則，子類儘可能不重寫父類方法
3. 繼承實際上讓兩個類的耦合性加強了，在適當狀況下，能夠經過依賴，聚合，組合來解決問題

開閉原則

介紹

1. 開閉原則（Open Closed Principle）是編程中最基礎，最重要的設計原則
2. 一個軟件實體，如類，模塊，函數應該對擴展開放（對提供方），對修改關閉（對使用方）。用抽象構建框架，用實現擴展細節
3. 當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化
4. 編程中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則

迪米特法則

介紹

1. 一個對象應該對其餘對象保持最少的瞭解
2. 類與類關係越密切，耦合度越大
3. 迪米特法則又叫最少知道原則，即一個類對本身依賴的類知道的越少越好。也就是說，被依賴的類無論多複雜，都儘可能將邏輯封裝在其內部，對外除了提供public方法，不泄露任何信息
4. 迪米特法則還有個更簡單的定義：只與直接朋友通訊
5. 直接朋友：每一個對象都會和其餘對象有耦合關係，只要對象間有耦合關係，咱們稱這兩個對象是朋友關係。耦合方式不少，有依賴，關聯，組合，聚合等。咱們稱在成員變量，方法參數，方法返回值中出現的類爲直接朋友，出如今局部變量中的類爲非直接朋友。陌生的類最好不要以局部變量的形式出如今類的內部

注意事項

1. 迪米特法則的核心是下降類之間的耦合
2. 可是注意：因爲每一個類都減小了沒必要要的依賴，迪米特法則只是要求下降類間（對象間）的耦合關係，並非要求徹底沒有依賴關係

合成複用法則

原則是儘可能使用合成/聚合的方式，而不是使用繼承

設計原則核心思想

1. 找出應用中可能須要變化之處，把它們獨立出來，不要和那些不須要變化的代碼混在一塊兒
2. 針對接口編程，而不是針對實現編程
3. 爲了交互對象之間的鬆耦合設計而努力

類關係

類之間的關係：依賴、泛化（繼承）、實現、關聯、聚合、組合

依賴關係

只要在類中用到了對方，那麼它們之間就存在依賴關係。

一個A類使用到了B類，就稱A依賴於B，可能有四種狀況：

1. B做爲A的成員變量
2. B做爲A的方法參數
3. B做爲A的方法返回值
4. B做爲A的局部變量，即在方法內部出現

泛化關係

泛化關係實際上就是繼承關係，它是依賴關係的特例

如A繼承了abstract B，就稱A和B存在泛化關係

實現關係

實現關係實際上就是實現接口，它是依賴關係的特例

如A實現了interface B，則A和B存在實現關係

關聯關係

關聯關係實際上就是類與類之間的聯繫，它是依賴關係的特例

關聯具備導航性，即單向關係或雙向關係

關聯具備多重性：如"1"(有且僅有一個), "0..."(0個或多個), "0, 1"(0個或1個), "n...m"(n到m個), "m..."(至少m個)

舉例

1. 單向一對一關係，如Person裏有一個IDCard
2. 雙向一對一關係，Person裏有一個IDCard，IDCard裏也有一個Person

聚合關係

聚合關係（Aggregation）表示總體和部分的關係，總體和部分能夠分開。聚合關係是關聯關係的特例

如一個Computer有KeyBoard和Monitor，組成電腦的配件能夠從電腦上分離出來

組合關係

組合關係也是總體和部分的關係，可是總體和部分不可分開。組合關係是關聯關係的特例

如一個Person有Head和IDCard，這裏Head和Person是組合關係，Head和Person不能分開（Head在Person建立時建立）。
另外，IDCard和Person就是聚合關係，Person能夠沒有IDCard（IDCard能夠經過set方法傳遞進來）

設計模式類型

設計模式分爲三種類型，共23種

1. 建立型模式：單例模式、抽象工廠模式、原型模式、建造者模式、工廠模式
2. 結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式
3. 行爲型模式：模板方法模式、命令模式、訪問者模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式（Interpreter模式）、狀態模式、策略模式、職責鏈模式（責任鏈模式）