里氏替換原則

我的博客原文：
里氏替換原則

設計模式六大原則之二：里氏替換原則。

簡介

姓名 ：里氏替換原則

英文名 ：Liskov Substitution Principle

座右銘 ：

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 subtype 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.
   全部引用基類的地方必須能透明地使用其子類的對象。

這 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

優缺點

下面再貼一下書本上的一些優缺點

優勢

1. 代碼共享，減小建立類的工做量，每一個子類都擁有父類的方法和屬性；
2. 提升代碼的重用性；
3. 子類能夠形似父類，但又異於父類，「龍生龍，鳳生鳳，老鼠生來會打洞」是說子擁有父的「種」，「世界上沒有兩片徹底相同的葉子」是指明子與父的不一樣；
4. 提升代碼的可擴展性，實現父類的方法就能夠「隨心所欲」了，君不見不少開源框架的擴展接口都是經過繼承父類來完成的；
5. 提升產品或項目的開放性。

缺點

1. 繼承是侵入性的。只要繼承，就必須擁有父類的全部屬性和方法；
2. 下降代碼的靈活性。子類必須擁有父類的屬性和方法，讓子類自由的世界中多了些約束；
3. 加強了耦合性。當父類的常量、變量和方法被修改時，須要考慮子類的修改，並且在缺少規範的環境下，這種修改可能帶來很是糟糕的結果————大段的代碼須要重構。
   (來自《設計模式之禪》)

總結

好了，里氏替換原則的大概原理講得差很少，你們只要記住是在定義「父子關係」，就像遊戲規則同樣，定義後讓你們遵照，會讓你們的程序在後面愈來愈複雜的時候也能清晰，而不會愈來愈亂。

參考資料：《大話設計模式》、《Java設計模式》、《設計模式之禪》、《研磨設計模式》、《Head First 設計模式》

但願文章對您有所幫助，設計模式系列會持續更新，感興趣的同窗能夠關注公衆號，第一時間獲取文章推送閱讀，也能夠一塊兒交流，交個朋友。

公衆號之設計模式系列文章