1 設計模式簡介

　　設計模式（Design pattern）代表了最佳的實踐，通常被有經驗的面向物件的軟體開發人員所採用。設計模式是軟體開發人員在軟體開發過程中面臨的一般問題的解決方案。這些解決方案是眾多軟體開發人員經過相當長的一段時間的試驗和錯誤總結出來的。

　　設計模式是一套被反覆使用的、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。專案中合理地運用設計模式可以完美地解決很多問題，每種模式在現實中都有相應的原理來與之對應，每種模式都描述了一個在我們周圍不斷重複發生的問題，以及該問題的核心解決方案，這也是設計模式能被廣泛應用的原因

2 設計模式的目的

　　編寫軟體過程中，程式設計師面臨著來自 耦合性，內聚性以及可維護性，可擴充套件性，重用性，靈活性 等多方面的挑戰，設計模式是為了讓程式(軟體)，具有更好

　　1) 程式碼重用性 (即：相同功能的程式碼，不用多次編寫)
　　2) 可讀性 (即：程式設計規範性, 便於其他程式設計師的閱讀和理解)
　　3) 可擴充套件性 (即：當需要增加新的功能時，非常的方便，稱為可維護)
　　4) 可靠性 (即：當我們增加新的功能後，對原來的功能沒有影響)
　　5) 使程式呈現高內聚，低耦合的特性

3 設計模式的七大原則

　　設計模式原則，其實就是程式設計師在程式設計時，應當遵守的原則，也是各種設計模式的基礎(即：設計模式為什麼這樣設計的依據)

　　　　1)單一職責原則

　　　　2) 介面隔離原則
　　　　3) 依賴倒轉(倒置)原則
　　　　4) 里氏替換原則
　　　　5) 開閉原則
　　　　6) 迪米特法則
　　　　7) 合成複用原則

3.1 單一職責原則

3.1.1 說明

　　對類來說的，即一個類應該只負責一項職責。如類 A 負責兩個不同職責：職責 1，職責 2。當職責 1 需求變更而改變 A 時，可能造成職責 2 執行錯誤，所以需要將類 A 的粒度分解為 A1，A2

3.1.2 注意事項

　　1) 降低類的複雜度，一個類只負責一項職責。
　　2) 提高類的可讀性，可維護性
　　3) 降低變更引起的風險
　　4) 通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在程式碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則

3.2 介面隔離原則

3.2.1 說明

　　客戶端不應該依賴它不需要的介面，即一個類對另一個類的依賴應該建立在最小的介面上

 　　類 A 通過介面 Interface1 依賴類 B，類 C 通過介面 Interface1 依賴類 D，如果介面 Interface1 對於類 A 和類 C來說不是最小介面，那麼類 B 和類 D 必須去實現他們不需要的方法。

　　按隔離原則應當這樣處理：將介面 Interface1 拆分為獨立的幾個介面(這裡我們拆分成 3 個介面)，類 A 和類 C 分別與他們需要的介面建立依賴關係。也就是採用介面隔離原則

3.3 里氏替換

3.3.1 說明

　　繼承包含這樣一層含義：父類中凡是已經實現好的方法，實際上是在設定規範和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞。

　　繼承在給程式設計帶來便利的同時，也帶來了弊端。比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能產生故障

　　所以有了里氏替換原則：

　　　　1) 里氏替換原則(Liskov Substitution Principle)在 1988 年，由麻省理工學院的以為姓裡的女士提出的。
　　　　2) 如果對每個型別為 T1 的物件 o1，都有型別為 T2 的物件 o2，使得以 T1 定義的所有程式 P 在所有的物件 o1 都代換成 o2 時，程式 P 的行為沒有發生變化，那麼型別 T2 是型別 T1 的子型別。換句話說，所有引用基類的地方必須能透明地使用其子類的物件。
　　　　3) 在使用繼承時，遵循里氏替換原則，在子類中儘量不要重寫父類的方法
　　　　4) 里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當的情況下，可以通過聚合，組合，依賴 來解決問題

3.4 依賴倒轉原則

3.4.1 說明

　　1) 高層模組不應該依賴低層模組，二者都應該依賴其抽象
　　2) 抽象不應該依賴細節，細節應該依賴抽象
　　3) 依賴倒轉(倒置)的中心思想是面向介面程式設計
　　4) 依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。在 java 中，抽象指的是介面或抽象類，細節就是具體的實現類
　　5) 使用介面或抽象類的目的是制定好規範，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成

3.4.2 注意事項

　　1) 低層模組儘量都要有抽象類或介面，或者兩者都有，程式穩定性更好.
　　2) 變數的宣告型別儘量是抽象類或介面, 這樣我們的變數引用和實際物件間，就存在一個緩衝層，利於程式擴充套件和優化
　　3) 繼承時遵循里氏替換原則

3.5 迪米特法則(最少知道法則)

3.5.1 說明　　

　　1) 一個物件應該對其他物件保持最少的瞭解
　　2) 類與類關係越密切，耦合度越大。迪米特法則的核心是降低類之間的耦合
　　3) 迪米特法則(Demeter Principle)又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都儘量將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外洩露任何資訊

3.6 合成複用原則

3.6.1 說明

　　找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的程式碼混在一起。

　　針對介面程式設計，而不是針對實現程式設計。

　　為了互動物件之間的鬆耦合設計而努力。原則是儘量使用合成/聚合的方式，而不是使用繼承

3.7 開閉原則

3.7.1 說明

　　1) 開閉原則（Open Closed Principle）是程式設計中最基礎、最重要的設計原則
　　2) 一個軟體實體如類，模組和函式應該對擴充套件開放(對提供方)，對修改關閉(對使用方)。用抽象構建框架，用實現擴充套件細節。
　　3) 當軟體需要變化時，儘量通過擴充套件軟體實體的行為來實現變化，而不是通過修改已有的程式碼來實現變化。
　　4) 程式設計中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。