長方形和正方形
正方形是否是長方形的子類的問題，西方一個很著名的思辨題。
正確的寫法是：
長方形類：兩個屬性，寬度和高度；正方形類：一個屬性，邊。
（LY注：這是至少流行了十年的思辨題目，最早來自于C++和Smalltalk領域。類似的這種思辨問題還有哪些呢？讓我不禁對哲學又感冒起來了。查閱資料時意外找到了一個討論區，里面有讀者和作者關于此處的拓展討論，真讓人高興。）
(LY注：書中沒有提契約即Design by Contract的概念。子類應當完全繼承父類的contract。《敏捷軟件開發：原則、模式與實踐》一書中這樣寫，"基于契約設計(Design By Constract),簡稱DBC"這項技術對LISKOV代換原則提供了支持.該項技術Bertrand Meyer伯特蘭做過詳細的介紹:使用DBC,類的編寫者顯式地規定針對該類的契約.客戶代碼的編寫者可以通過該契約獲悉可以依賴的行為方式.契約是通過每個方法聲明的前置條件(preconditions)和后置條件(postconditions)來指定的.要使一個方法得以執行,前置條件必須為真.執行完畢后,該方法要保證后置條件為真.就是說,在重新聲明派生類中的例程(routine)時,只能使用相等或者更弱的前置條件來替換原始的前置條件,只能使用相等或者更強的后置條件來替換原始的后置條件。 本書中長方形的Contract是width和height可以獨立變化，這個contract在正方形中被破壞了。)
（LY注：注意，我們所有討論的基礎都應由類的行為決定。這使得長方形等類是動態的，而不是象現實生活中一樣是靜態的概念。）
正方形不可以作為長方形的子類
如果設定一個resize方法，一直增加長方形的寬度，直到增加到寬度超過高度才可以。
那么如果針對子類正方形的對象調用resize方法，這個方法會導致正方形的邊不斷地增加下去，直到溢出為止。換言之，里氏法則被破壞掉了。
這個例子很重要，它意味著里氏代換與通常的數學法則和生活常識有不可混淆的區別。
(LY 注：常識認為，正方形is a 長方形，而且是一類特殊的長方形。但是在這里出了問題，如果我們系統中不會有這樣的resize操作，是否正方形就可以作為長方形的子類了呢？看后文是可以的)
代碼的重構
長方形和正方形到底應該是什么關系呢？
它們應該都是四邊形類的子類。四邊形類中沒有賦值方法，因類似上文的resize()方法不可能適用于四邊形類，而只能只用于不同的具體子類長方形和正方形。因此里氏代換原則不會被破壞。（LY注：針對需要賦值操作的情況）
從抽象類繼承
應盡量從抽象類繼承，而不是從具體類繼承。
上文對長方形和正方形的重構使用了重構的第一種方法。增加一個抽象類，讓兩個具體類都成為抽象類的子類。
記住一條指導性的原則，如果有一個由繼承關系形成的等級結構的話，在等級結構樹圖上的所有樹葉節點都應當是具體類；而所有的樹枝節點都應當是抽象類或者Java接口。
問答題
1、 一個有名的思辨題，filename能不能作為string類的子類？
答：不能。Filename對象不能實現string對象的所有行為。比如兩個string對象相加可以給出一個新的有效的string對象。而兩個filename對象相加未必會得到一個新的有效的Filename對象。
另外，Java中的String類型是final類型，因此不可以繼承。
2、 如果正方形的邊長不會發生改變，是否可以成為長方形的子類呢？（LY注：不變正方形，就是邊長不會發生變化的正方形，也就是遵守不變模式的正方形。不變(Immutable)模式,一個對象在對象在創建之后就不再變化。）
答：可以。實現時，父類有兩個屬性寬度和高度。子類有三個屬性寬度、高度和邊。針對每一個屬性，包含一個內部變量，一個Set值方法，一個Get值方法。子類正方形只需要將Set值方法不寫任何語句即可。
3、 從里式代換角度看Java中Properties和Hashtable的關系是否合適？
答：不合適。在Java中，Properties是Hashtable的子類。顯然Properties是一種特殊的Hashtable,它只接受string類型的鍵（Key）和值（Value）。但是，父類Hashtable可以接受任何類型的鍵和值。這意味著，在一些需要非String類型的鍵和值的地方，Properties不能取代Hashtable。
（LY注：合成/聚合復用原則中有更詳細的討論，應使用合成/組合而不是繼承。它們是has a的關系而不是is a的關系。）