【設計模式六大原則】里氏替換原則

確定有很多人跟我剛看到這項原則的時候同樣，對這個原則的名字充滿疑惑。其實緣由就是這項原則最先是在1988年，由麻省理工學院的一位姓裏的女士（Barbara Liskov）提出來的。

定義1：若是對每個類型爲 T1的對象 o1，都有類型爲 T2 的對象o2，使得以 T1定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。

定義2：全部引用基類的地方必須能透明地使用其子類的對象。

問題由來：有一功能P1，由類A完成。現須要將功能P1進行擴展，擴展後的功能爲P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會致使原有功能P1發生故障。

解決方案：當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，儘可能不要重寫父類A的方法，也儘可能不要重載父類A的方法。

繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），其實是在設定一系列的規範和契約，雖然它不強制要求全部的子類必須聽從這些契約，可是若是子類對這些非抽象方法任意修改，就會對整個繼承體系形成破壞。而里氏替換原則就是表達了這一層含義。

繼承做爲面向對象三大特性之一，在給程序設計帶來巨大便利的同時，也帶來了弊端。好比使用繼承會給程序帶來侵入性，程序的可移植性下降，增長了對象間的耦合性，若是一個類被其餘的類所繼承，則當這個類須要修改時，必須考慮到全部的子類，而且父類修改後，全部涉及到子類的功能都有可能會產生故障。

舉例說明繼承的風險，咱們須要完成一個兩數相減的功能，由類A來負責。

        class A{

         public int func1(int a, int b){

         return a-b;

         }

        }

        

        public class Client{

         public static void main(String[] args){

         A a = new A();

         System.out.println("100-50="+a.func1(100, 50));

         System.out.println("100-80="+a.func1(100, 80));

         }

        } 

運行結果：

100-50=50

100-80=20

後來，咱們須要增長一個新的功能：完成兩數相加，而後再與100求和，由類B來負責。即類B須要完成兩個功能：

• 兩數相減。

• 兩數相加，而後再加100。

因爲類A已經實現了第一個功能，因此類B繼承類A後，只須要再完成第二個功能就能夠了，代碼以下：

class B extends A{

public int func1(int a, int b){

return a+b;

}

public int func2(int a, int b){

return func1(a,b)+100;

}

}

public class Client{

public static void main(String[] args){

B b = new B();

System.out.println("100-50="+b.func1(100, 50));

System.out.println("100-80="+b.func1(100, 80));

System.out.println("100+20+100="+b.func2(100, 20));

}

} 

類B完成後，運行結果：

100-50=150

100-80=180

100+20+100=220

咱們發現本來運行正常的相減功能發生了錯誤。緣由就是類B在給方法起名時無心中重寫了父類的方法，形成全部運行相減功能的代碼所有調用了類B重寫後的方法，形成本來運行正常的功能出現了錯誤。在本例中，引用基類A完成的功能，換成子類B以後，發生了異常。在實際編程中，咱們經常會經過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，可是整個繼承體系的可複用性會比較差，特別是運用多態比較頻繁時，程序運行出錯的概率很是大。若是非要重寫父類的方法，比較通用的作法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關係去掉，採用依賴、聚合，組合等關係代替。

里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。它包含如下4層含義：

• 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。

• 子類中能夠增長本身特有的方法。

• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。

• 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

看上去很難以想象，由於咱們會發如今本身編程中經常會違反里氏替換原則，程序照樣跑的好好的。因此你們都會產生這樣的疑問，假如我非要不遵循里氏替換原則會有什麼後果？

後果就是：你寫的代碼出問題的概率將會大大增長。