java設計模式01-----設計原則

前言

近期一直再學習設計模式，現主要對組件協作模式以及設計原則進行知識梳理。學習設計模式核心就是看見代碼中的變與不變，變化是複用的天敵。我對設計模式的理解就是更好地實現複用。設計模式的使用也不宜先入爲主，一上來就使用設計模式是對設計的最大誤用，沒有一步到位的設計模式。敏捷開發實踐所提倡的“Refactoring to Patterns”（重構到設計模式）是目前普遍公認的最好的使用設計模式的方法。

設計原則

設計原則我所見到的幾個有些細微的差別，但核心都是不變的，現總結如下。

1. 開閉原則（Open Close Principle，OCP）

定義：對擴展開放，對修改關閉
作用：保證以前代碼的準確性，使開發者更專注於新擴展的代碼上，從而使得整個系統的魯棒性。用通俗的話說就是：代碼寫好了，就不要修改源代碼了，而是進行擴展。

2. 單一職責原則（Single Responsibility Principle）

定義：一個類只負責一個功能領域的職責。
作用：降低類的複雜度，當修改一個功能時，降低對其他功能的影響，提供類的可讀性。當然也是爲了低耦合。

3.里氏代換原則（Liskov Substitution Principle）

定義：任何基類出現的地方，子類一定可以出現
作用：在程序中儘量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象，開閉原則實現的手段之一。里氏替換原則通俗來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。也就是說：子類繼承父類時，除添加新的方法完成新增功能外，**儘量不要重寫父類的方法。**如果通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，但是整個繼承體系的可複用性會比較差，特別是運用多態比較頻繁時，程序運行出錯的概率會非常大。如果程序違背了里氏替換原則，則繼承類的對象在基類出現的地方會出現運行錯誤。這時其修正方法是：取消原來的繼承關係，重新設計它們之間的關係。¹
也就是說，如果繼承之後再重寫父類中已經實現的方法，就已經證明，這個子類不應該繼承這個父類，父類中具體的方法，應該是所有子類所具有的共同特點。

4.依賴倒轉原則（Dependence Inversion Principle）

定義：高層模塊（穩定）不應該依賴於低層模塊（變化），二者都應該依賴於抽象（穩定）。抽象不應該依賴於實現細節，實現細節應該依賴於抽象。這裏的抽象就是穩定的意思，實現就是變化。換句話說：針對接口編程
作用：依賴倒置原則可以降低類間的耦合性。
依賴倒置原則可以提高系統的穩定性。
依賴倒置原則可以減少並行開發引起的風險。
依賴倒置原則可以提高代碼的可讀性和可維護性。
依賴倒置原則的目的是通過要面向接口的編程來降低類間的耦合性，所以我們在實際編程中只要遵循以下4點，就能在項目中滿足這個規則。

1. 每個類儘量提供接口或抽象類，或者兩者都具備。
2. 變量的聲明類型儘量是接口或者是抽象類。
3. 任何類都不應該從具體類派生。
4. 使用繼承時儘量遵循里氏替換原則^[1]
   設計時所畫的UML圖，裏面的依賴關係，依賴的對象不應該是一個具體的對象，而是一個抽象的東西。

5.接口隔離原則（Interface Segregation Principle）

定義：使用多個專門的接口，不使用單一的總接口。現假設有一個接口有12345,5
個方法，第一個實現類只使用123，第二個實現類只使用145，那麼這個接口就應該進行隔離。隔離層三個接口，分別包含1,23,45。
接口隔離原則和單一職責都是爲了提高類的內聚性、降低它們之間的耦合性，體現了封裝的思想，但兩者是不同的：
單一職責原則注重的是職責，而接口隔離原則注重的是對接口依賴的隔離。
單一職責原則主要是約束類，它針對的是程序中的實現和細節；接口隔離原則主要約束接口，主要針對抽象和程序整體框架的構建。

6.迪米特法則（Law Of Demeter）

定義：一個實體應當儘量少的與其他實體發生相互作用。**如果兩個軟件實體無須直接通信，那麼就不應當發生直接的相互調用，可以通過第三方轉發該調用。**其目的是降低類之間的耦合度，提高模塊的相對獨立性。
沒必要直接通信，而又需要調用，就是用一箇中間件進行過渡。

7.合成複用原則（Composite Reuse Principle）

定義：它要求在軟件複用時，要儘量先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現。
**如果要使用繼承關係，則必須嚴格遵循里氏替換原則。**合成複用原則同里氏替換原則相輔相成的，兩者都是開閉原則的具體實現規範。
使用方式：就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分，新的對象通過這些對象的委派達到複用已有功能的目的。

在後面的設計模式中會有體現。

參考文獻

[1]http://c.biancheng.net/view/1324.html
[2]https://blog.csdn.net/zy52002520/article/details/80577607

---

1. 1 ↩︎