設計模式-OOD的設計原則(2)-"里氏代換原則"

      從上一篇的"開-閉"原則中可以看出,面向對象設計的重要原則是創建抽象化,並且從抽象化導出具體化.這個導出要使用繼承關係和一個原則:里氏代換原則(Liskov Substitution Principle, LSP).
      那麼什麼是里氏代換原則呢?有個嚴格的表述,繞口,不好記.還是比較白話的這個好記.說的是:一個軟件實體如果使用的是一個基類的話,那麼一定適用於其子類,而且它察覺不出基類對象和子類對象的區別.也就是說,在軟件裏面,把基類都替換成它的子類,程序的行爲沒有變化.
      LSP是繼承複用的基石,只有當衍生類可以替換掉基類,軟件單位的功能不受到影響時,基類才能真正被複用,而衍生類也能夠在基類的基礎上增加新的行爲.
      下面,我們從代碼重構的角度來對LSP進行理解.LSP講的是基類和子類的關係.只有當這種關係存在時,里氏代換關係才存在.如果兩個具體的類A,B之間的關係違反了LSP的設計,(假設是從B到A的繼承關係)那麼根據具體的情況可以在下面的兩種重構方案中選擇一種.
  1. 創建一個新的抽象類C,作爲兩個具體類的超類,將A,B的共同行爲移動到C中來解決問題.
  2. 從B到A的繼承關係改爲委派關係.

      爲了說明,我們先用第一種方法來看一個例子,第二種辦法在另外一個原則中說明.我們就看那個著名的長方形和正方形的例子.對於長方形的類,如果它的長寬相等,那麼它就是一個正方形,因此,長方形類的對象中有一些正方形的對象.對於一個正方形的類,它的方法有個setSide和getSide,它不是長方形的子類,和長方形也不會符合LSP.

      那麼,如果讓正方形當做是長方形的子類,會出現什麼情況呢?我們讓正方形從長方形繼承,然後在它的內部設置width等於height,這樣,只要width或者height被賦值,那麼width和height會被同時賦值,這樣就保證了正方形類中,width和height總是相等的.現在我們假設有個客戶類,其中有個方法,規則是這樣的,測試傳人的長方形的寬度是否大於高度,如果滿足就停止下來,否則就增加寬度的值.現在我們來看,如果傳人的是基類長方形,這個運行的很好.根據LSP,我們把基類替換成它的子類,結果應該也是一樣的,但是因爲正方形類的width和height會同時賦值,這個方法沒有結束的時候,條件總是不滿足,也就是說,替換成子類後,程序的行爲發生了變化,它不滿足LSP.

      那麼我們用第一種方案進行重構,我們構造一個抽象的四邊形類,把長方形和正方形共同的行爲放到這個四邊形類裏面,讓長方形和正方形都是它的子類,問題就OK了.對於長方形和正方形,取width和height是它們共同的行爲,但是給width和height賦值,兩者行爲不同,因此,這個抽象的四邊形的類只有取值方法,沒有賦值方法.上面的例子中那個方法只會適用於不同的子類,LSP也就不會被破壞.

      在進行設計的時候,我們儘量從抽象類繼承,而不是從具體類繼承.如果從繼承等級樹來看,所有葉子節點應當是具體類,而所有的樹枝節點應當是抽象類或者接口.當然這個只是一個一般性的指導原則,使用的時候還要具體情況具體分析.

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章