OCP作為OO的高層原則，主張使用“抽象(Abstraction)”和“多態(tài)(Polymorphism)”將設(shè)計(jì)中的靜態(tài)結(jié)構(gòu)改為動態(tài)結(jié)構(gòu)，維持設(shè)計(jì)的封閉性。

“抽象”是語言提供的功能。“多態(tài)”由繼承語義實(shí)現(xiàn)。

如此，問題產(chǎn)生了：“我們?nèi)绾稳ザ攘坷^承關(guān)系的質(zhì)量？”

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

該原則稱為Liskov Substitution Principle——里氏替換原則。林先生在上課時(shí)風(fēng)趣地稱之為“老鼠的兒子會打洞”。^_^

我們來研究一下LSP的實(shí)質(zhì)。學(xué)習(xí)OO的時(shí)候，我們知道，一個(gè)對象是一組狀態(tài)和一系列行為的組合體。狀態(tài)是對象的內(nèi)在特性，行為是對象的外在特性。LSP所表述的就是在同一個(gè)繼承體系中的對象應(yīng)該有共同的行為特征。

這一點(diǎn)上，表明了OO的繼承與日常生活中的繼承的本質(zhì)區(qū)別。舉一個(gè)例子：生物學(xué)的分類體系中把企鵝歸屬為鳥類。我們模仿這個(gè)體系，設(shè)計(jì)出這樣的類和關(guān)系。

?

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

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

修正后的設(shè)計(jì)如下：

?

但是，這就是LSP的全部了么？書中給了一個(gè)經(jīng)典的例子，這又是一個(gè)不符合常理的例子：正方形不是一個(gè)長方形。這個(gè)悖論的詳細(xì)內(nèi)容能在網(wǎng)上找到，我就不多廢話了。

LSP并沒有提供解決這個(gè)問題的方案，而只是提出了這么一個(gè)問題。

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

1. 每個(gè)方法調(diào)用之前，該方法應(yīng)該校驗(yàn)傳入?yún)?shù)的正確性，只有正確才能執(zhí)行該方法，否則認(rèn)為調(diào)用方違反契約，不予執(zhí)行。這稱為前置條件(Pre-condition)。
2. 一旦通過前置條件的校驗(yàn)，方法必須執(zhí)行，并且必須確保執(zhí)行結(jié)果符合契約，這稱之為后置條件(Post-condition)。
3. 對象本身有一套對自身狀態(tài)進(jìn)行校驗(yàn)的檢查條件，以確保該對象的本質(zhì)不發(fā)生改變，這稱之為不變式(Invariant)。

以上是單個(gè)對象的約束條件。為了滿足LSP，當(dāng)存在繼承關(guān)系時(shí)，子類中方法的前置條件必須與超類中被覆蓋的方法的前置條件相同或者更寬松；而子類中方法的后置條件必須與超類中被覆蓋的方法的后置條件相同或者更為嚴(yán)格。

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

• 繼承并且覆蓋超類方法的時(shí)候，子類中的方法的可見性必須等于或者大于超類中的方法的可見性，子類中的方法所拋出的受檢異常只能是超類中對應(yīng)方法所拋出的受檢異常的子類。
  public?class?SuperClass{
  ????public?void?methodA()?throws?IOException{}
  }
  
  public?class?SubClassA?extends?SuperClass{
  ????//this?overriding?is?illegal.
  ????private?void?methodA()?throws?Exception{}
  }
  
  public?class?SubClassB?extends?SuperClass{
  ????//this?overriding?is?OK.
  ????public?void?methodA()?throws?FileNotFoundException{}
  }
  
  
• 從Java5開始，子類中的方法的返回值也可以是對應(yīng)的超類方法的返回值的子類。這叫做“協(xié)變”(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呢？很遺憾，主流的面向?qū)ο笳Z言（不論是動態(tài)語言還是靜態(tài)語言）還沒有加入對DbC的支持。但是隨著AOP概念的產(chǎn)生，相信不久DbC也將成為OO語言的一個(gè)重要特性之一。