我們來研究壹下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這樣的概念不斷地強化，接口表達了對象行為之間的“契約”關系。而不是簡單地作為壹種實現多繼承的語法糖。