設計模式7大設計原則

設計模式常用的7大原則：

1、單一職責原則

2、接口隔離原則

3、依賴倒轉(倒置)原則

4、里氏替換原則

5、開閉原則

6、迪米特法則

7、合成複用原則

設計模式是爲了代碼或者軟件具有更好的1、重用性（相同功能的代碼不用重複編寫）；2、可讀性（其他程序員可以理解）；3、可擴展性（增加新功能很方便）；4、可靠性（新功能對原功能沒有影響）；5、代碼出現高內聚，低耦合的特性；

單一職責原則：

介紹：一個類應該只負責一個職責，如果A類負責兩個不同的職責：職責1和職責2，那麼當職責1修改時，職責2可能受到干擾，因此，應該將A類粒度細分爲A1和A2。

單一職責分爲兩種：類單一職責和方法單一職責。

類單一職責例子：

方法單一職責例子：

單一職責原則注意事項和細節：

1、降低了類的複雜度；

2、提高了類的可讀性，可維護性；

3、降低了變更引起的風險；

4、通常情況下應遵循單一職責原則，除非代碼邏輯足夠簡單，纔可以違反單一職責原則，只有類中方法足夠少，纔可以違反方法單一職責原則；

接口隔離原則：

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

爲什麼要用接口隔離原則？請看下面的例子：

依賴倒轉原則：

依賴倒轉原則是指：

1、高層模塊不應該依賴於低層模塊，二者都應該依賴其抽象；

2、抽象不應該依賴於細節，應該細節依賴於抽象；

3、依賴倒轉原則的中心思想是面向接口編程；

4、依賴倒轉原則基於這樣的設計理念：相對於多變的細節，抽象則穩定的多。以抽象爲基礎搭建的架構，比以細節爲基礎搭建的架構要穩定的多。在java中，抽象指的是接口或者抽象類。細節是指具體的實現類。

5、使用接口或者抽象類的目的是爲了制定好規範，而不涉及具體的操作，把展現細節的任務交給實現類去完成。

依賴關係傳遞的三種方式和應用案例：

1、接口傳遞

2、構造方法傳遞

3、set方法傳遞。

里氏替換原則：

OO中的繼承性思考和說明：

1）繼承包含了這一層含義：父類中已經實現好了的方法，實際上是在設定規範和契約，雖然它不強制它的子類必須遵守這些契約，但是如果子類對這些已經實現了的方法任意修改，則會對它的繼承性造成一定破壞。

2）繼承在給程序設計帶來便利的同時，也帶來了一定的弊端，比如使用繼承會給程序帶來一定的侵入性。程序的可移植性降低，增加了對象之間的耦合性，如果一個類被其他的類繼承，則這個類修改的同時也得考慮其他子類。並且父類修改後，可能給子類帶來故障。

3）問題提出：在編程中如何合理的使用繼承？==》里氏替換原則（子類繼承父類，最好不要重寫父類方法）

基本介紹：

1、里氏替換原則（Lis Substitution Principle）在1988年，由麻省理工學院的以姓裏的女士（這位女士還獲得了2008年的圖靈獎）提出的。

2、對每個類型爲T1的對象o1，都有類型爲T2的對象o2，使得T1定義的所有程序p在所有的對象o1都代換成o2時，程序p的行爲沒有發生任何變化，那麼類型T2爲類型T1的子類型。換句話說：所有引用基類的地方必須的透明的使用子類型。

3、在使用繼承時，遵循里氏替換原則，在子類中最好不要重寫父類的方法。

4、里氏替換原則原則告訴我們實際上兩個類的耦合性增強了，在適當的情況下可以通過聚合、組合、依賴來解決問題。或者也可以將類中公共的方法提取出來成爲一個公共接口，讓其他類也實現這個公共接口。

改進方案：

開閉原則：

1）開閉原則（Open Closed Principle）是編程中最基礎、最重要的原則

2）一個軟件實體，如類、模塊和函數應該對擴展開放，對修改關閉。用抽象構建框架，用實現擴展細節。

3）當軟件需要變化時，儘量通過擴展軟件實體的行爲來實現變化，而不是通過修改原來的代碼來實現變化。

4）編程中使用其他原則，以及使用設計模式的目的就是遵循開閉原則。

下圖是非人類使用方法：

這種方法最大的問題是如果添加類的修改代碼。

改進方案：

這樣新增一個類就無需修改使用方代碼。

迪米特法則：

1）一個對象應該對其他的對象保持最少的瞭解。

2）類與類關係越密切，耦合度越大。

3）迪米特法則（Demeter Principle）也叫最少知道原則，即一個類應該對自己依賴的類知道的越少越好。

也就是說對被依賴的類不管多複雜，都應該將邏輯封裝在類的內部，對外除了提供public的方法外，不對外泄露任何信息。

4）迪米特法則還有個更簡單的定義：只與直接朋友通信。

5）直接朋友：每個對象都與其他對象有耦合關係，只要兩個對象之間有耦合關係，我們就說對象之間是朋友關係。耦合的方式有很多，其中包括：關聯、泛化、實現、依賴、聚合、耦合（下一章節要講）等等。其中，我們稱出現在成員變量、方法參數、方法中的變量、方法返回值的類爲直接朋友，而出現在局部變量中的類不是直接的朋友。也就是說陌生的類最好還是不要以局部變量的方式出現在類的內部。

迪米特法則的需要注意事項和細節：

1）迪米特法則的核心思想時降低類和類之間的耦合

2）但要注意：由於每個類都減少不必要的依賴，因此迪米特法則只是要求降低類間（對象）間的耦合關係，並不是要求完全沒有依賴關係。

合成複用原則：

儘量使用合成/聚合的方式，少用繼承。

設計模式的核心思想：

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

2）針對接口編程，而不是針對實現細節編程。

3）爲了實現交互對象之間的松耦合而努力。

UML圖：

1）uml--unified modeling language UML(統一建模語言)是一種用於軟件分析和設計的語言工具。它用於幫助軟件開發人員進行思考和記錄的結果。

2）uml本身是一套符號化的規定，就像數學符號和化學符號一樣，這些詞符號用於描述軟件模型中的各個元素和他們之間的關係，比如類、接口、實現、依賴、組合、聚合等。如下圖：