1. 程式人生 > >(轉)設計模式六大原則(2):里氏替換原則

(轉)設計模式六大原則(2):里氏替換原則

     肯定有不少人跟我剛看到這項原則的時候一樣,對這個原則的名字充滿疑惑。其實原因就是這項原則最早是在1988年,由麻省理工學院的一位姓裡的女士(Barbara Liskov)提出來的。

定義1:如果對每一個型別為 T1的物件 o1,都有型別為 T2 的物件o2,使得以 T1定義的所有程式 P 在所有的物件 o1 都代換成 o2 時,程式 P 的行為沒有發生變化,那麼型別 T2 是型別 T1 的子型別。

定義2:所有引用基類的地方必須能透明地使用其子類的物件。

問題由來:有一功能P1,由類A完成。現需要將功能P1進行擴充套件,擴充套件後的功能為P,其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成,則子類B在完成新功能P2的同時,有可能會導致原有功能P1發生故障。

解決方案:當使用繼承時,遵循里氏替換原則。類B繼承類A時,除新增新的方法完成新增功能P2外,儘量不要重寫父類A的方法,也儘量不要過載父類A的方法。

         繼承包含這樣一層含義:父類中凡是已經實現好的方法(相對於抽象方法而言),實際上是在設定一系列的規範和契約,雖然它不強制要求所有的子類必須遵從這些契約,但是如果子類對這些非抽象方法任意修改,就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。

        繼承作為面向物件三大特性之一,在給程式設計帶來巨大便利的同時,也帶來了弊端。比如使用繼承會給程式帶來侵入性,程式的可移植性降低,增加了物件間的耦合性,如果一個類被其他的類所繼承,則當這個類需要修改時,必須考慮到所有的子類,並且父類修改後,所有涉及到子類的功能都有可能會產生故障。

        舉例說明繼承的風險,我們需要完成一個兩數相減的功能,由類A來負責。

  1. class A{  
  2.     publicint func1(int a, int b){  
  3.         return a-b;  
  4.     }  
  5. }  
  6. publicclass Client{  
  7.     publicstaticvoid main(String[] args){  
  8.         A a = new A();  
  9.         System.out.println("100-50="+a.func1(10050));  
  10.         System.out.println("100-80="
    +a.func1(10080));  
  11.     }  
  12. }  


 執行結果:

100-50=50
100-80=20

        後來,我們需要增加一個新的功能:完成兩數相加,然後再與100求和,由類B來負責。即類B需要完成兩個功能:

  • 兩數相減。
  • 兩數相加,然後再加100。

        由於類A已經實現了第一個功能,所以類B繼承類A後,只需要再完成第二個功能就可以了,程式碼如下:

  1. class B extends A{  
  2.     publicint func1(int a, int b){  
  3.         return a+b;  
  4.     }  
  5.     publicint func2(int a, int b){  
  6.         return func1(a,b)+100;  
  7.     }  
  8. }  
  9. publicclass Client{  
  10.     publicstaticvoid main(String[] args){  
  11.         B b = new B();  
  12.         System.out.println("100-50="+b.func1(10050));  
  13.         System.out.println("100-80="+b.func1(10080));  
  14.         System.out.println("100+20+100="+b.func2(10020));  
  15.     }  
  16. }  

類B完成後,執行結果:

100-50=150
100-80=180
100+20+100=220

        我們發現原本執行正常的相減功能發生了錯誤。原因就是類B在給方法起名時無意中重寫了父類的方法,造成所有執行相減功能的程式碼全部呼叫了類B重寫後的方法,造成原本執行正常的功能出現了錯誤。在本例中,引用基類A完成的功能,換成子類B之後,發生了異常。在實際程式設計中,我們常常會通過重寫父類的方法來完成新的功能,這樣寫起來雖然簡單,但是整個繼承體系的可複用性會比較差,特別是運用多型比較頻繁時,程式執行出錯的機率非常大。如果非要重寫父類的方法,比較通用的做法是:原來的父類和子類都繼承一個更通俗的基類,原有的繼承關係去掉,採用依賴、聚合,組合等關係代替。

        里氏替換原則通俗的來講就是:子類可以擴充套件父類的功能,但不能改變父類原有的功能。它包含以下4層含義:

  • 子類可以實現父類的抽象方法,但不能覆蓋父類的非抽象方法。
  • 子類中可以增加自己特有的方法。
  • 當子類的方法過載父類的方法時,方法的前置條件(即方法的形參)要比父類方法的輸入引數更寬鬆。
  • 當子類的方法實現父類的抽象方法時,方法的後置條件(即方法的返回值)要比父類更嚴格。

        看上去很不可思議,因為我們會發現在自己程式設計中常常會違反里氏替換原則,程式照樣跑的好好的。所以大家都會產生這樣的疑問,假如我非要不遵循里氏替換原則會有什麼後果?

        後果就是:你寫的程式碼出問題的機率將會大大增加。

相關推薦

設計模式六大原則2里氏替換原則

     肯定有不少人跟我剛看到這項原則的時候一樣,對這個原則的名字充滿疑惑。其實原因就是這項原則最早是在1988年,由麻省理工學院的一位姓裡的女士(Barbara Liskov)提出來的。 定義1:如果對每一個型別為 T1的物件 o1,都有型別為 T2 的物件o2,使

設計模式六大原則3依賴倒置原則

定義:高層模組不應該依賴低層模組,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。 問題由來:類A直接依賴類B,假如要將類A改為依賴類C,則必須通過修改類A的程式碼來達成。這種場景下,類A一般是高層模組,負責複雜的業務邏輯;類B和類C是低層模組,負責基本的原子

設計模式六大原則1單一職責原則

定義:不要存在多於一個導致類變更的原因。通俗的說,即一個類只負責一項職責。 問題由來:類T負責兩個不同的職責:職責P1,職責P2。當由於職責P1需求發生改變而需要修改類T時,有可能會導致原本執行正常的職責P2功能發生故障。 解決方案:遵循單一職責原則。分別建立兩個類T1

設計模式六大原則詳細 設計模式六大原則

設計模式六大原則 轉自https://www.cnblogs.com/shijingjing07/p/6227728.html 1.設計模式的目的設計模式是為了更好的程式碼重用性,可讀性,可靠性,可維護性。 2.常用的六大設計模式1)單一職責原則2)里氏替換原則3)依賴倒轉原則4)介面

設計模式六大原則2里氏替換原則

      肯定有不少人跟我剛看到這項原則的時候一樣,對這個原則的名字充滿疑惑。其實原因就是這項原則最早是在1988年,由麻省理工學院的一位姓裡的女士(Barbara Liskov)提出來的。 定義1:如果對每一個型別為 T1的物件 o1,都有型別為 T2 的物件o2,

設計模式六大原則里氏替換原則

里氏替換原則:   子類應當可以替換父類並出現在父類能夠出現的地方。比如:公司搞年度派對,都有員工都可以抽獎,那麼不管是新員工還是老員工,也不管是總部員工還是外派員工,都應當可以參加抽獎。 案例: 1 internal class Program 2 { 3 private s

設計模式六大原則

method 過多 這樣的 不同 提高 依賴倒置 同心圓 23種設計模式 變化 設計模式六大原則(1):單一職責原則 定義:不要存在多於一個導致類變更的原因。通俗的說,即一個類只負責一項職責。 問題由來:類T負責兩個不同的職責:職責P1,職責P2。當由於職責P1需求發

設計模式六大原則6開閉原則

思考 外部 編程人員 恰恰 單一職責 何事 適應 擴展 分享 開閉原則 定義:一個軟件實體如類、模塊和函數應該對擴展開放,對修改關閉。 問題由來:在軟件的生命周期內,因為變化、升級和維護等原因需要對軟件原有代碼進行修改時,可能會給舊代碼中引入錯誤,也可能會使我們不得不對

設計模式六大原則2裏氏替換原則

tr1 裏氏替換原則 style tar 裏氏替換 href target 替換 設計模式 XN潮寺贛3PF鋁73瓷Hhttp://weibo.com/p/1005056364252732 壇2偈6v實8uka誆敲wmhttp://weibo.com/p/10050563

設計模式六大原則4接口隔離原則

說明 兩個 復雜 試圖 所有 類圖 系統 客戶端 face 定義:客戶端不應該依賴它不需要的接口;一個類對另一個類的依賴應該建立在最小的接口上。 問題由來:類A通過接口I依賴類B,類C通過接口I依賴類D,如果接口I對於類A和類B來說不是最小接口,則類B和類D必須去實現他

python 設計模式 --- 六大原則

單一職責原則(SRP:Single responsibility principle),一個類或者模組應該有且只有一個改變的原因,例如,搓衣板,既可以用來跪,也可以用來洗衣服。而在單一職責原理下,搓衣板的兩個功能就是引起這個類變化的兩個原因,就應該寫成兩個類 # -*-

設計模式六大原則例子-- 介面隔離原則ISP例子

之前我們對設計模式的六大原則做了簡單歸納,這篇部落格是對介面隔離原則進行的舉例說明。 1介面隔離原則的意義 建立單一介面,不要建立龐大臃腫的介面,儘量細化介面,介面中的方法儘量少。也就是說,我們要為各個類建立專用的介面,而不要試圖去建立一個很龐大的介面供所有依賴它的類去呼叫。 在程式設計中,依賴幾個

設計模式六大原則-- 介面隔離原則ISP

  設計圖和原始碼請訪問作者的github:https://github.com/yangsheng20080808/DesignModel From Now On,Let us begin Design Patterns。 介面隔離原則 Interface Segregati

設計模式六大原則3依賴倒置原則

定義:高層模組不應該依賴低層模組,二者都應該依賴其抽象;抽象不應該依賴細節;細節應該依賴抽象。 問題由來:類A直接依賴類B,假如要將類A改為依賴類C,則必須通過修改類A的程式碼來達成。這種場景下,類A一般是高層模組,負責複雜的業務邏輯;類B和類C是低層模組,負責基本的原子操作

設計模式六大原則的理解

       面向物件三大特徵:“封裝”,“繼承”,“多型”碼農們都能順口唸出,但設計模式的三大原則能準確說出的就不多了。這三大原則是“開放-封閉原則“,”里氏代換原則”和“依賴倒轉的原則”。      開放---封閉原則:  軟體實體可以擴充套件,但是不可以修改(當然錯誤

設計模式六大原則4介面隔離原則

定義:客戶端不應該依賴它不需要的介面;一個類對另一個類的依賴應該建立在最小的介面上。 問題由來:類A通過介面I依賴類B,類C通過介面I依賴類D,如果介面I對於類A和類B來說不是最小介面,則類B和類D必須去實現他們不需要的方法。 解決方案:將臃腫的介面I拆分為獨立的幾個介面,

設計模式六大原則1單一職責原則Single Responsibility Principle

單一職責原則(Single Responsibility Principle) 定義:不要存在多於一個導致類變更的原因。通俗的說,即一個類只負責一項職責。 問題由來:類T負責兩個不同的職責:職責P1,職責P2。當由於職責P1需求發生改變而需要修改類T時,有

設計模式六大原則5迪米特法則

定義:一個物件應該對其他物件保持最少的瞭解。 問題由來:類與類之間的關係越密切,耦合度越大,當一個類發生改變時,對另一個類的影響也越大。 解決方案:儘量降低類與類之間的耦合。          自從我們接觸程式設計開始,就知道了軟體程式設計的總的原則:低耦合,高內聚。

設計模式六大原則例子-- 單一職責原則SRP例子

之前我們對設計模式的六大原則做了簡單歸納,這篇部落格是對單一職責原則進行的舉例說明。 單一職責原則的意義 物件不應該承擔太多職責,正如人不應該一心分為二用。唯有專注,才能保證物件的高內聚;唯有單一,才能保證物件的細粒度。物件的高內聚與細粒度有利於物件的

設計模式六大設計原則開閉原則

開發十年,就只剩下這套架構體系了! >>>