里氏替換原則究竟如何理解？

介紹里氏替換原則的文章非常多，但可能大家看完之后，心中仍然留有疑問，如何去落地實現，如何判斷是否影響程序功能，本文將帶領大家深入理解里氏替換，一起領略下它的真正面目，但在此之前，有必要闡述一下，為什么會提出設計原則以及設計原則的作用，

什么是設計原則設計原則是指導代碼設計的經驗沉淀，其目的是為了提高軟件開發的可維護性，我們知道，程序世界并非一塵不染的，隨著業務的發展，之前所設計的流程，會為了適應業務而不斷調整改變， 對于開發來說，需要有業務前瞻性，凡事多往前考慮一步，盡量減少因為未來業務改變，而造成系統大范圍的改動，一旦大范圍改動，勢必造成開發和回歸的成本，所以開發的時候，多思考這樣的設計是否違背了某些原則，如果能盡量向上述的設計原則靠攏，就能達到可維護性的目的，常用的有以下設計原則，后續會逐步推出系列文章，一一講解

• SOLID原則
• SRP 單一職責原則
• OCP 開閉原則
• LSP 里式替換原則
• ISP 接口隔離原則
• DIP 依賴倒置原則
• DRY 原則
• KISS 原則
• YAGNI 原則
• LOD 法則

我們來正式討論本文主角，里氏替換原則，里氏替換原則的定義是

調用父類的地方，可以替換成調用子類，但是不會導致程序出錯

這里核心的點在于，替換之后，程序不會出錯，即不能導致程序邏輯錯誤，運行錯誤，

以我的理解，里氏替換原則對于代碼設計的約束可以分為兩個角度進行討論，方法結構的約束和方法邏輯約束，下面我們逐個深入討論

1. 方法結構的約束（方法定義）

1.1 輸入參數不能比父類嚴格

即入參只能是父類入參或者父類入參的父類，即如果父類方法的入參是 P 類，那么子類方法的入參只能是 P 類，或者 P 類的父類， 

我們舉例說明一下， 下面的例子中， 我們定義了三個類， A，B， C， 其中 B 和 C 是 A 的子類，B 類的入參是P，比父類的寬松，滿足法則，而 C 類的入參是 P2，比父類的嚴格，不滿足法則，

之所以這樣做，是為了避免子類使用了更加寬松的入參類型中，特有的一些方法，而導致程序出錯，

比如下面的例子中，調用了 A 類的 test 方法，并且入參是 P 類，接著用 C 類替換 A 類的位置，同樣執行 test 方法，入參還是 P，但是執行會報錯（先不考慮編譯問題，假設傳參能夠成功），因為 C 類的 test 方法中，調用了 p2Method 方法，

而這個方案是 P 的子類 P2 的獨有方法，

class P {
    private void method(){};
}

class P1 extend P {
}

class P2 extend P1{
    private void p2Method(){};
}

class A {
    private void test(P1 p){};
}

// 符合
class B extend A {
    private void test(P p){};
}

// 不符合
class C extend A {
    private void test(P2 p){
        p.p2Method();
    };
}


P p = new P();

A a = new A();
a.test(p);

C c = new C();
// 執行失敗，因為 P 沒有 p2Method 方法，如果用c替換掉a，則會失敗
c.test(p);

1.2 回傳值不能比父類寬松

即返回值只能是父類返回值，或者父類返回值的子類， 

下面的例子中，父類A的返回值是 R1， B的返回值類型是 R2， 滿足規則，而 C 的返回值是 R，不滿足規則， 之所以要這樣做，是因為如果子類返回的類型更加寬松，會導致調用方調用出錯，

比如下面的例子中 A 執行了 test方法，返回值是 R1，此時調用 r1Method 是合法的，而如果用 C 類替換掉 A類的位置，因為 C 的test 方法返回是 R，沒有r1Method方法，所以調用會出錯，（先忽略編譯失敗的問題）

class R {
    private void method(){};
}

class R1 extend R {
    private void r1Method(){};
}

class R2 extend R1{
    private void r2Method(){};
}

class A {
    private R1 test(){
        ...
    };
}

// 符合
class B extend A {
    private R2 test(){
        ...
    };
}

// 不符合
class C extend A {
    private R test(){
        ...
    };
}


A a = new A();
R1 r = a.test();
r.r1Method();

C c = new C();
R1 r = c.test(p);
// 執行失敗，因為 c.test 的回傳值實際上是 R 類，沒有 r1Method 方法
r.r1Method();

實際上，方法定義上是否滿足里氏替換法則，對于靜態語言，編譯器會做方法定義的合法性校驗，更為重要的在于邏輯上是否滿足里氏替換原則，這點需要開發人員自己把控， 也更加重要

2. 方法的邏輯

除了在方法定義，在代碼邏輯實現的時候，也需要遵循一些約束，做到代碼通過了編譯校驗的同時，在運行中也不會出現意想不到的錯誤情況，

2.1 對入參的邏輯處理不能比父類嚴格

這里的邏輯處理指的是條件判斷，類型轉換等等，

下面用兩個例子來說明，第一個例子是關于類型轉換的邏輯，這里有三個參數類，P，P1，P2，其中 P1 和 P2 是 P 的子類， 

A 類提供了 test 方法，并且接收的 入參是 P 類，B 類繼承自 A 類，所不同的是， B 類重新實現了 test 方法， 
我們注意到， B 的 test 方法中，對入參 P 類進行了強轉，雖然是符合語法約束的，但在某些場景下會出現問題，比如在調用 B 類的 test 方法時，傳了 P2，那么強轉就會失敗了，

class P {
    private void method(){...};
}

class P1 extend P {
    private void p1Method(){...};
}

class P2 extend P {
    private void p2Method(){...};
}

class A {
    private void test(P p){...};
}

class B extend A {
private void test(P p){    // 這里做了強制轉換    P1 p = (P1)p;
    p.p1Method();
};
}


// 這樣處理沒問題
P p = new P1();
A a = new B();
a.test(P1);

// 但如果入參是 P2，就會報錯了，因為B類中，會將入參強制轉換成 P1，型別轉換失敗
P p = new P2();
A a = new B();
a.test(P1);

這個例子并非屬于極端例子，如果翻看一下實際的應用代碼，我相信比比皆是， 那對于這種場景，我們應該怎樣去做調整呢？

標籤：架構設計

上一篇：復雜業務系統的通用架構設計法則

下一篇：返回列表