學習設計模式，以《設計模式之禪》為藍本進行總結與學習，今天先記錄設計模式六大原則的兩個原則：單一職責原則（SRP）和里氏替換原則（LSP）。

單一職責原則

Single Responsibility Principle(SRP):There should never be more than one reason for a class to change.

看如下一個設計：

思考問題：

1、協議接通的變化會引起這個介面或實現類的變化嗎？

2、那資料傳送（想想看，電話不僅僅可以通話，還可以上網）的變化會引起這個介面或實現類的變化嗎？

很顯然會引起變化，這就不符合單一職責原則了，需要做如下改進：

改進後，上述兩種情況的變化僅會引起一個介面的變化而不影響其他介面。

單一職責的好處：

1、類的複雜性降低，實現什麼職責都有清晰明確的定義；

2、可讀性提高，因為複雜性降低，所以可讀性提高；

3、可維護性提高，可讀性提高，當然更加容易維護；

4、變更引起的風險降低，變更是必不可少的，如果介面的單一職責做得好，一個介面修改只對相應的實現類有影響，對其他的介面無影響，這對系統的擴充套件性、維護性都有非常大的幫助。

單一職責原則提出了一個編寫程式的標準，用“職責”或“變化原因”來衡量介面或類設計得是否優良，但是“職責”和“變化原因”都是不可度量的，因專案而異，因環境而異。

下面給出一個方法關聯了太多的職責：

改進的類：

改進後，呼叫更加明確。

對於單一職責原則，我的建議是介面一定要做到單一職責，類的設計儘量做到只有一個原因引起變化。

里氏替換原則

Liskov Substitution Principle(LSP), definition:

1、If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a sub type of T.

如果對每一個型別為S的物件o1，都有型別為T的物件o2，使得以T定義的所有程式P在所有的物件o1都代換成o2時，程式P的行為沒有發生變化，那麼型別S是型別T的子型別。

2、Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

所有引用基類的地方必須能透明地使用其子類的物件。

第二個定義是最清晰明確的，通俗點講，只要父類能出現的地方子類就可以出現，而且替換為子類也不會產生任何錯誤或異常，使用者可能根本就不需要知道是父類還是子類。但是，反過來就不行了，有子類出現的地方，父類未必就能適應。

LSP為繼承定義了良好的原則：

1、子類必須完全實現父類的方法。

CS遊戲中的應用類圖：

如果有一把玩具槍(ToyGun），該如何實現？注意：玩具槍不可以射擊。

2、子類可以有自己的個性。

3、覆蓋或實現父類的方法時輸入引數可以被放大。

里氏替換原則要求制定一個契約，就是父類或介面，這種設計方法也叫做DesignbyContract（契約設計）。契約制定了，也就同時制定了前置條件和後置條件，前置條件就是你要讓我執行，就必須滿足我的條件；後置條件就是我執行完了需要反饋。

方法中的輸入引數稱為前置條件，過載時，要求方法的輸入引數型別或數量不相同，在里氏替換原則要求下，就是子類的輸入引數寬於或等於父類的輸入引數，也就是說你寫的這個方法是不會被呼叫的。

4、覆寫或實現父類的方法時輸出結果可以被縮小。

父類的一個方法的返回值是一個型別T，子類的相同方法（過載或覆寫）的返回值為S，那麼里氏替換原則就要求S必須小於等於T。

採用里氏替換原則的目的就是增強程式的健壯性，版本升級時也可以保持非常好的相容性。即使增加子類，原有的子類還可以繼續執行。在實際專案中，每個子類對應不同的業務含義，使用父類作為引數，傳遞不同的子類完成不同的業務邏輯，非常完美！