里氏替換原則，OCP作為OO的高層原則，主張使用“抽象(Abstraction)”和“多態(tài)(Polymorphism)”將設計中的靜態(tài)結構改為動態(tài)結構，維持設計的封閉性。“抽象”是語言提供的功能?！岸鄳B(tài)”由繼承語義實現(xiàn)。

里氏替換原則包含以下4層含義：

1. 子類可以實現(xiàn)父類的抽象方法，但是不能覆蓋父類的非抽象方法。
2. 子類中可以增加自己特有的方法。
3. 當子類覆蓋或實現(xiàn)父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松。
4. 當子類的方法實現(xiàn)父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

　　現(xiàn)在我們可以對以上四層含義進行講解。

　　子類可以實現(xiàn)父類的抽象方法，但是不能覆蓋父類的非抽象方法

　　在我們做系統(tǒng)設計時，經常會設計接口或抽象類，然后由子類來實現(xiàn)抽象方法，這里使用的其實就是里氏替換原則。子類可以實現(xiàn)父類的抽象方法很好理解，事實上，子類也必須完全實現(xiàn)父類的抽象方法，哪怕寫一個空方法，否則會編譯報錯。

　　里氏替換原則的關鍵點在于不能覆蓋父類的非抽象方法。父類中凡是已經實現(xiàn)好的方法，實際上是在設定一系列的規(guī)范和契約，雖然它不強制要求所有的子類必須遵從這些規(guī)范，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。

　　在面向對象的設計思想中，繼承這一特性為系統(tǒng)的設計帶來了極大的便利性，但是由之而來的也潛在著一些風險。下面舉例來說明繼承的風險，我們需要完成一個兩數(shù)相減的功能，由類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

        后來，我們需要增加一個新的功能：完成兩數(shù)相加，然后再與100求和，由類B來負責。即類B需要完成兩個功能：
兩數(shù)相減。
兩數(shù)相加，然后再加100。
        由于類A已經實現(xiàn)了第一個功能，所以類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

        我們發(fā)現(xiàn)原本運行正常的相減功能發(fā)生了錯誤。原因就是類B在給方法起名時無意中重寫了父類的方法，造成所有運行相減功能的代碼全部調用了類B重寫后的方法，造成原本運行正常的功能出現(xiàn)了錯誤。在本例中，引用基類A完成的功能，換成子類B之后，發(fā)生了異常。在實際編程中，我們常常會通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，但是整個繼承體系的可復用性會比較差，特別是運用多態(tài)比較頻繁時，程序運行出錯的幾率非常大。如果非要重寫父類的方法，比較通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關系去掉，采用依賴、聚合，組合等關系代替。

最新評論