設計模式六大原則（2）：裡氏替換原則

標籤：style   class   code   java   ext   color   

        肯定有不少人跟我剛看到這項原則的時候一樣，對這個原則的名字充滿疑惑。事實上原因就是這項原則最早是在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層含義：

• 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 子類中能夠添加自己特有的方法。
• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
• 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

        看上去非常不可思議，由於我們會發如今自己編程中經常會違反裡氏替換原則，程式照樣跑的好好的。所以大家都會產生這種疑問，假如我非要不遵循裡氏替換原則會有什麼後果？

        後果就是：你寫的代碼出問題的幾率將會大大添加。