設計模式之六大原則

設計模式之設計原則

這軟件設計過程當中，有六大設計原則：

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

因爲軟件開發過程當中，根據業務不一樣等因素造成了各類複雜的而不可預料的需求，遵照原則，讓項目開發過程與維護過程當中，減小付出更多的時間與努力而達到更好的實現功能。須要對經驗，不斷總結，不斷實踐，對將設計模式使用的更熟練，對軟件開發起到意想不到的做用。

如下對六大設計原則，鄙人的一些簡單述說：

單一職責原則

定義：
作到有且只有一個緣由引發類的變動，也就是說一個接口作一件事，這件事能概況某一事物的某一職責。

問題由來：
類T負責兩個不一樣的職責，職責P1，職責P2，當職責P1需求發生變化時，須要修改P2功能，有可能會致使本來運行正常功能發生故障

解決方案：
將T的P1，P2兩個職責使用T1，T2分別完成，T1負責P1功能，T2負責P2功能，當T1發生改變，T2不會發生改變，T2發生改變，T1也不會發生改變。

因爲每一個職責都進行分開，會出現大量類，當某一職責進行分解時，須要修改大量的代碼，此時修改職責類中的代碼違反單一職責（代碼級別，方法級別），減小大量類出現。

適用狀況：

1. 接口
   必要時能夠將接口中的屬性和行爲進行分解，這樣能夠作到單一職責。
2. 方法
   方法中的參數過多，能夠對方法的參數進行分解，能夠作到單一職責。

總結：
使用接口和方法的方式，儘可能作到只有一個緣由引發對這個類的改變。
單一職責原則，不僅是面向對象編程，還適合模塊化編程等。

在實際項目中，因爲功能過於複雜等緣由作到該原則，仍是挺難的，儘可能作到單一職責原則，。

里氏替換原則

定義：
簡單點說就是隻要父類出現的地方，子類就能夠出現，且替換成子類後，也不能出現任何錯誤與異常（子類出現後，父類不能由於子類的出現致使父類出問題），致使出現錯誤緣由：子類繼承父類，重寫父類方法後，這時父類方法功能就失效，發生變化。

意義：
子類能夠擴展父類的功能，但不能改變父類原有的功能

繼承機制的優勢：

1. 代碼共享，減小建立類的工做量
2. 提升代碼的重用性
3. 子類能夠形似父類，又異於父類，
4. 提升父類的擴展性，實現父類的方法便可隨意而爲

缺點：

1. 繼承是入侵性的，（擁有父類的全部屬性和方法）
   
2. 下降了代碼的靈活性，（因爲父類屬性的約束，致使子類的約束更多）
   
3. 加強了耦合性，（當父類的常量，變量，方法被修改，需考慮對子類的影響）

總結： 當違反了里氏替換原則後，能夠將父類和子類抽取出更加通用的基類，使用依賴，聚合，組合燈關係，下降繼承的缺點。

依賴倒置原則

定義：

1. 高層模塊不該該依賴低層模塊，二者都應該依賴其抽象
2. 抽象不該該依賴細節
3. 細節應該依賴抽象

在代碼中能夠理解成：

1. 模塊間的依賴經過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是經過接口或者抽象類產生的
   
2. 接口或者抽象類不依賴於實現類
   
3. 實現類依賴於接口或者抽象類

此時能夠更簡潔的理解成： 面向接口編程

總結：

依賴致使原則本職就是經過抽象（抽象類或者接口）使各個類或者模塊實現彼此獨立，不相互影響，實現模塊的鬆耦合。

在實際使用項目中，儘可能使用以下規則：

1. 每一個類儘可能都要有接口或者抽象類，或者抽象類和接口都有（依賴倒置原則定義要由抽象才能實現依賴倒置）

2. 變量表面類型儘可能是接口或者抽象類

3. 任何類都不該該從具體類派生

4. 儘可能不要重寫基類已經寫好的方法（裏式替換原則）

5. 結合裏式替換原則來使用（依賴原則和裏式原則總結：接口負責定義public屬性和方法，並聲明與其餘對象的依賴關係，抽象類負責公共構造部分的實現，實現類準確的實現業務邏輯，並在適當的時候對父類進行細化）

接口隔離原則

咱們先來看接口的定義 :

實例接口 : 在 Java 中聲明一個類,而後用 new 關鍵字產生一個實例,它是對一類事物的描述,能夠當作是一個接口
類接口 : 使用 interface 定義的接口
隔離的的理解 :

1. 客戶端不該該依賴它不須要的接口
   
2. 類之間的依賴關係應該創建在最小的接口上

歸納 : 創建單一接口,不要創建臃腫龐大的接口,也就是接口儘可能細化,接口中的方法儘可能少
這個是開閉原則的基礎，具體內容：針對接口編程，依賴於抽象而不依賴於具體。

接口隔離原則的約束條件 :

接口要高內聚,意思就是提升接口,類,模塊的處理能力,減小對外的交互,再具體一點就是在接口中儘可能減小對外的 public 方法,經過業務邏輯壓縮接口中的 public 方法

定製服務,就是單獨爲一個個體提供優良的服務,好比咱們寫用戶模塊的時候,須要給用戶提供查詢信息,修改密碼,註冊用戶等信息,當管理員執行相同操做的時候,通常人會複用這些方法,

而後在這個的基礎上再增長管理員本身的方法,這種設計方法確定是有問題的,這樣設計,當你修改了普通用戶調用的接口實現時,管理員的實現也會發生不可預測的改變,咱們應該爲管理員單獨寫一個接口

接口設計是有限度的,接口的設計粒度越小,系統越靈活,這是確定的,但靈活的同時帶來的問題是 結構複雜化,開發難度增長, 可維護性下降

一個接口只服務於一個子模塊或業務邏輯

已經被污染了的接口,儘可能去修改 ,若修改的風險較大,則採用適配器模式進行轉化處理

瞭解環境,拒絕盲從,不要一味的去套設計模式,有的時候不用比用了更好,也不要去照搬別人的設計方法,他的方法到你這不必定效果就好,畢竟業務邏輯不同

迪米特法則

定義 : 迪米特法則也叫最少知識原則,含義是 一個對象應該對其餘對象有最少的瞭解,這個應該很好理解,就是下降各模塊之間的耦合

開閉原則

定義 : 一個軟件實體如類,模塊和函數應該對擴展開放,對修改關閉,開閉原則也是其餘五個原則的基石