設計模式六大原則之二：里氏替換原則。
簡介
姓名 ：里氏替換原則
英文名 ：Liskov Substitution Principle
座右銘 ：
-
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 subtype of T.
如果對每一個類型爲S的對象o1，都有類型爲T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行爲沒有發生變化，那麼類型S是類型T的子類型。 - Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基類的地方必須能透明地使用其子類的對象。
這 2 個定義來自《設計模式之禪》，比較乾巴巴，不認真思考起來可能不太容易懂。簡單來說就是定義了什麼是父子。在現實生活中，什麼是父子？就是生你的那個男人和你的關係就是父子（父女）。而這裏定義的就是假如 A 能勝任 B 乾的所有事情，那 B 就是 A 的父親，也就是兒子要會父親的所有能活，兒子活得再爛也要有父親的水平。
價值觀 ：很顯然，比較傳統，嚴父出孝子。兒子必須要有父親的能耐，最好青出於藍勝於藍。
伴侶 ：估計有個賢惠的老婆，纔能有這麼優秀的兒子。
個人介紹 ：我比較嚴厲，也是爲了生存沒辦法，只有一輩一輩地變優秀，一直堅持下去，家族就會越來越好。這樣就可以富過三代，你看你們人類不是經常說富不過三代。。。扎心了老鐵，老子還是富零代。
老爹開車，前方注意
里氏替換原則定義了什麼是父子，還有一點要注意的，就是兒子不能在父親會的技能上搞“創新”。
比如父親會做紅燒排骨，兒子在新東方烹飪學校中學到了一招，在紅燒排骨裏面加糖和醋，變成紅燒糖醋排骨，更加美味，看代碼，兒子在父親的基礎紅燒排骨上加了糖醋，好像沒啥問題。
class Father1 {
public void braisedRibs(){
System.out.println("紅燒排骨");
}
}
class Son1 extends Father1 {
public void braisedRibs(){
System.out.println("紅燒糖醋排骨");
}
}
運行下面代碼，會打印：紅燒排骨
Father1 father1 = new Father1();
father1.braisedRibs();我們上面說過，所有在使用父親的地方，都能夠替換成兒子，並且效果是一樣的，那接下來我們改一下代碼。
Son1 son1 = new Son1();
son1.braisedRibs();結果是啥？打印出：紅燒糖醋排骨，出乎意料吧。。。這結果完全不一樣。想一下上面說的：老爸會的老子也要會，很明顯，上面的例子老子不會紅燒排骨，只會紅燒糖醋排骨，所以這根本不是父子關係。
那應該怎麼實現呢？其實紅燒排骨和紅燒糖醋排骨這壓根就是 2 道菜，你去餐館吃飯的時候，你點紅燒排骨服務員給你送來紅燒糖醋排骨，或者你點紅燒糖醋排骨服務員給你送來紅燒排骨，你這時候不生氣，算我輸。
來看看 Son2，Son2 將紅燒糖醋改爲 braisedSweetAndSourPorkRibs （翻譯不好找 Google 算賬去哈，反正不是我翻譯的）。
class Son2 extends Father1 {
public void braisedSweetAndSourPorkRibs(){
System.out.println("紅燒糖醋排骨");
}
}測試一下是不是好兒子
Son2 son2 = new Son2();
son2.braisedRibs();
son2.braisedSweetAndSourPorkRibs();打印出：
紅燒排骨
紅燒糖醋排骨
這纔是 Father1 的好兒子嘛，不僅會紅燒排骨，還會紅燒糖醋排骨。所以說里氏替換原則就是在定義父子關係，大家都遵守這個定義，就會一代比一代好，不遵守大家也看到了，把前輩傳下來的都毀於一旦了。
代碼見：LSPTest.java
優缺點
下面再貼一下書本上的一些優缺點
優點
- 代碼共享，減少創建類的工作量，每個子類都擁有父類的方法和屬性；
- 提高代碼的重用性；
- 子類可以形似父類，但又異於父類，“龍生龍，鳳生鳳，老鼠生來會打洞”是說子擁有父的“種”，“世界上沒有兩片完全相同的葉子”是指明子與父的不同；
- 提高代碼的可擴展性，實現父類的方法就可以“爲所欲爲”了，君不見很多開源框架的擴展接口都是通過繼承父類來完成的；
- 提高產品或項目的開放性。
缺點
- 繼承是侵入性的。只要繼承，就必須擁有父類的所有屬性和方法；
- 降低代碼的靈活性。子類必須擁有父類的屬性和方法，讓子類自由的世界中多了些約束；
- 增強了耦合性。當父類的常量、變量和方法被修改時，需要考慮子類的修改，而且在缺乏規範的環境下，這種修改可能帶來非常糟糕的結果————大段的代碼需要重構。
(來自《設計模式之禪》)
總結
好了，里氏替換原則的大概原理講得差不多，大家只要記住是在定義“父子關係”，就像遊戲規則一樣，定義後讓大家遵守，會讓大家的程序在後面越來越複雜的時候也能清晰，而不會越來越亂。
希望文章對您有所幫助，設計模式系列會持續更新，感興趣的同學可以關注公衆號LieBrother，第一時間獲取文章推送閱讀，也可以一起交流，交個朋友。
