里氏替換原則

里氏替換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。里氏替換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。

如此，問題產生了：“我們如何去度量繼承關係的質量？”

Liskov於1987年提出了一個關於繼承的原則“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“繼承必須確保超類所擁有的性質在子類中仍然成立。”也就是說，當一個子類的實例應該能夠替換任何其超類的實例時，它們之間才具有is-A關係。

該原則稱為Liskov Substitution Principle——里氏替換原則。

我們來研究一下LSP的實質。學習OO的時候，我們知道，一個對象是一組狀態和一系列行為的組合體。狀態是對象的內在特性，行為是對象的外在特性。LSP所表述的就是在同一個繼承體系中的對象應該有共同的行為特徵。

這一點上，表明了OO的繼承與日常生活中的繼承的本質區別。舉一個例子：生物學的分類體系中把企鵝歸屬為鳥類。我們模仿這個體系，設計出這樣的類和關係。

類“鳥”中有個方法fly，企鵝自然也繼承了這個方法，可是企鵝不能飛阿，於是，我們在企鵝的類中覆蓋了fly方法，告訴方法的調用者：企鵝是不會飛的。這完全符合常理。但是，這違反了LSP，企鵝是鳥的子類，可是企鵝卻不能飛！需要注意的是，此處的“鳥”已經不再是生物學中的鳥了，它是軟體中的一個類、一個抽象。

有人會說，企鵝不能飛很正常啊，而且這樣編寫代碼也能正常編譯，只要在使用這個類的客戶代碼中加一句判斷就行了。但是，這就是問題所在！首先，客戶代碼和“企鵝”的代碼很有可能不是同時設計的，在當今軟體外包一層又一層的開發模式下，你甚至根本不知道兩個模塊的原產地是哪裡，也就談不上去修改客戶代碼了。客戶程序很可能是遺留系統的一部分，很可能已經不再維護，如果因為設計出這麼一個“企鵝”而導致必須修改客戶代碼，誰應該承擔這部分責任呢？（大概是上帝吧，誰叫他讓“企鵝”不能飛的。^_^）“修改客戶代碼”直接違反了OCP，這就是OCP的重要性。違反LSP將使既有的設計不能封閉！

修正後的設計如下：

但是，這就是LSP的全部了么？書中給了一個經典的例子，這又是一個不符合常理的例子：正方形不是一個長方形。這個悖論的詳細內容能在網上找到，我就不多廢話了。

LSP並沒有提供解決這個問題的方案，而只是提出了這麼一個問題。

於是，工程師們開始關注如何確保對象的行為。1988年，B. Meyer提出了Design by Contract（契約式設計）理論。DbC從形式化方法中借鑒了一套確保對象行為和自身狀態的方法，其基本概念很簡單：

Pre-condition:

每個方法調用之前，該方法應該校驗傳入參數的正確性，只有正確才能執行該方法，否則認為調用方違反契約，不予執行。這稱為前置條件(Pre-condition)。

Post-Condition:

一旦通過前置條件的校驗，方法必須執行，並且必須確保執行結果符合契約，這稱之為後置條件(Post-condition)。

Invariant:

對象本身有一套對自身狀態進行校驗的檢查條件，以確保該對象的本質不發生改變，這稱之為不變式(Invariant)。

以上是單個對象的約束條件。為了滿足LSP，當存在繼承關係時，子類中方法的前置條件必須與超類中被覆蓋的方法的前置條件相同或者更寬鬆；而子類中方法的後置條件必須與超類中被覆蓋的方法的後置條件相同或者更為嚴格

一些OO語言中的特性能夠說明這一問題：

繼承並且覆蓋超類方法的時候，子類中的方法的可見性必須等於或者大於超類中的方法的可見性，子類中的方法所拋出的受檢異常只能是超類中對應方法所拋出的受檢異常的子類。

public class SuperClass{

public void methodA() throws Exception{}

}

public class SubClassA extends SuperClass{

//this overriding is illegal.

private void methodA() throws IOException{}

}

public class SubClassB extends SuperClass{

//this overriding is OK.

public void methodA() throws FileNotFoundException{}

}

從Java5開始，子類中的方法的返回值也可以是對應的超類方法的返回值的子類。這叫做“協變”(Covariant)

public class SuperClass {

public Number caculate(){

return null;

}

}

public class SubClass extends SuperClass{

//only compiles in Java 5 or later.

public Integer caculate(){

return null;

}

}

可以看出，以上這些特性都非常好地遵循了LSP。但是DbC呢？很遺憾，主流的面向對象語言（不論是動態語言還是靜態語言）還沒有加入對DbC的支持。但是隨著AOP概念的產生，相信不久DbC也將成為OO語言的一個重要特性之一。

一些題外話：

前一陣子《敲響OO時代的喪鐘》和《喪鐘為誰而鳴》兩篇文章引來了無數議論。其中提到了不少OO語言的不足。事實上，遵從LSP和OCP，不管是靜態類型還是動態類型系統，只要是OO的設計，就應該對對象的行為有嚴格的約束。這個約束並不僅僅體現在方法簽名上，而是這個具體行為的本身。這才是LSP和DbC的真諦。從這一點來說並不能說明“萬事萬物皆對象”的動態語言和“C++，Java”這種“按介面編程”語言的優劣，兩類語言都有待於改進。庄兄對DJ的設想倒是開始引入DbC的概念了。這一點還是非常值得期待的。^_^

另外，介面的語義正被OCP、LSP、DbC這樣的概念不斷地強化，介面表達了對象行為之間的“契約”關係。而不是簡單地作為一種實現多繼承的語法糖。