里氏替換原則
前言：今天是3.15，一個特殊的日子。不知道還會曝光出多少家不良企業，更不知道潛藏的未被曝光的企業數量之巨有沒有超出我的想象力。每年都會爆出一些諸如“塑化劑、毒膠囊、問題奶、速成雞”等等新的食品安全關鍵詞，走進餐館，走進食堂，走進超市，還真不知道什么東西敢碰。新的問題一年一年曝光，卻一年比一年嚴重。不良商家究竟還有沒有底線？說好的節操呢？
設計模式系列文章
1、問題的由來
我們都知道面向對象有三大特性：封裝、繼承、多態。所以我們在實際開發過程中，子類在繼承父類后，根據多態的特性，可能是圖一時方便，經常任意重寫父類的方法，那么這種方式會大大增加代碼出問題的幾率。比如下面場景：類C實現了某項功能F1。現在需要對功能F1作修改擴展，將功能F1擴展為F，其中F由原有的功能F1和新功能F2組成。新功能F由類C的子類C1來完成，則子類C1在完成功能F的同時，有可能會導致類C的原功能F1發生故障。這時候里氏替換原則就閃亮登場了。
2、什么是里氏替換原則
前面說過的單一職責原則，從字面意思就很好理解，但是里氏替換原則就有點讓人摸不着頭腦。查過資料后發現原來這項原則最早是在1988年，由麻省理工學院一位姓里的女士（Liskov）提出來的。
英文縮寫：LSP (Liskov Substitution Principle)。
嚴格的定義：如果對每一個類型為T1的對象o1，都有類型為T2的對象o2，使得以T1定義的所有程序P在所有的對象o1都換成o2時，程序P的行為沒有變化，那么類型T2是類型T1的子類型。
通俗的定義：所有引用基類的地方必須能透明地使用其子類的對象。
更通俗的定義：子類可以擴展父類的功能，但不能改變父類原有的功能。
代碼示例
//抽象父類電腦
public abstract class Computer {
public abstract void use();
}
class IBM extends Computer{
@Override
public void use() {
System.out.println("use IBM Computer.");
}
}
class HP extends Computer{
@Override
public void use() {
System.out.println("use HP Computer.");
}
}
public class Client{
public static void main(String[] args) {
Computer ibm = new IBM();
Computer hp = new HP();//引用基類的地方能透明地使用其子類的對象。
ibm.use();
hp.use();
}
}
3、四層含義
里氏替換原則包含以下4層含義：
- 子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法。
- 子類中可以增加自己特有的方法。
- 當子類覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
- 當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。
現在我們可以對以上四層含義逐個講解。
子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法
在我們做系統設計時，經常會設計接口或抽象類，然后由子類來實現抽象方法，這里使用的其實就是里氏替換原則。子類可以實現父類的抽象方法很好理解，事實上，子類也必須完全實現父類的抽象方法，哪怕寫一個空方法，否則會編譯報錯。
里氏替換原則的關鍵點在於不能覆蓋父類的非抽象方法。父類中凡是已經實現好的方法，實際上是在設定一系列的規范和契約，雖然它不強制要求所有的子類必須遵從這些規范，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。
在面向對象的設計思想中，繼承這一特性為系統的設計帶來了極大的便利性，但是由之而來的也潛在着一些風險。就像開篇所提到的那一場景一樣，對於那種情況最好遵循里氏替換原則，類C1繼承類C時，可以添加新方法完成新增功能，盡量不要重寫父類C的方法。否則可能帶來難以預料的風險，比如下面一個簡單的例子還原開篇的場景：
public class C {
public int func(int a, int b){
return a+b;
}
}
public class C1 extends C{
@Override
public int func(int a, int b) {
return a-b;
}
}
public class Client{
public static void main(String[] args) {
C c = new C1();
System.out.println("2+1=" + c.func(2, 1));
}
}
運行結果：2+1=1
上面的運行結果明顯是錯誤的。類C1繼承C，后來需要增加新功能，類C1並沒有新寫一個方法，而是直接重寫了父類C的func方法，違背里氏替換原則，引用父類的地方並不能透明的使用子類的對象，導致運行結果出錯。
子類中可以增加自己特有的方法
在繼承父類屬性和方法的同時，每個子類也都可以有自己的個性，在父類的基礎上擴展自己的功能。前面其實已經提到，當功能擴展時，子類盡量不要重寫父類的方法，而是另寫一個方法，所以對上面的代碼加以更改，使其符合里氏替換原則，代碼如下：
public class C {
public int func(int a, int b){
return a+b;
}
}
public class C1 extends C{
public int func2(int a, int b) {
return a-b;
}
}
public class Client{
public static void main(String[] args) {
C1 c = new C1();
System.out.println("2-1=" + c.func2(2, 1));
}
}
運行結果：2-1=1
當子類覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松
代碼示例
import java.util.HashMap;
public class Father {
public void func(HashMap m){
System.out.println("執行父類...");
}
}
import java.util.Map;
public class Son extends Father{
public void func(Map m){//方法的形參比父類的更寬松
System.out.println("執行子類...");
}
}
import java.util.HashMap;
public class Client{
public static void main(String[] args) {
Father f = new Son();//引用基類的地方能透明地使用其子類的對象。
HashMap h = new HashMap();
f.func(h);
}
}
運行結果：執行父類...
注意Son類的func方法前面是不能加@Override注解的，因為否則會編譯提示報錯，因為這並不是重寫（Override），而是重載（Overload），因為方法的輸入參數不同。重寫和重載的區別在Java面向對象詳解一文中已作解釋，此處不再贅述。
當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格
代碼示例：
import java.util.Map;
public abstract class Father {
public abstract Map func();
}
import java.util.HashMap;
public class Son extends Father{
@Override
public HashMap func(){//方法的返回值比父類的更嚴格
HashMap h = new HashMap();
h.put("h", "執行子類...");
return h;
}
}
public class Client{
public static void main(String[] args) {
Father f = new Son();//引用基類的地方能透明地使用其子類的對象。
System.out.println(f.func());
}
}
執行結果：{h=執行子類...}
4、總結
繼承作為面向對象三大特性之一，在給程序設計帶來巨大便利的同時，也帶來了一些弊端，它增加了對象之間的耦合性。因此在系統設計時，遵循里氏替換原則，盡量避免子類重寫父類的方法，可以有效降低代碼出錯的可能性。