里氏替換原則

1、里氏替換原則Liskov Substitution Principle, LSP 第4組名字的由來名字的由來（Liskov Substitution Principle, LSP）里氏代換原則以Barbara Liskov（芭芭拉利斯科夫）教授的姓氏命名。最早是在1988年，由麻省理工學院的女教授（芭芭拉利斯科夫）提出來的。芭芭拉利斯科夫：美國計算機科學家，2008年圖靈獎得主，2004年約翰馮諾依曼獎得主，美國工程院院士，美國藝術與科學院院士，美國計算機協(xié)會會士，麻省理工學院電子電氣與計算機科學系教授，美國第一位計算機科學女博士。目錄繼承的弊端2431 里氏替換原則的定義 里氏替換原則包含的

2、 含義使用該原則注意事項一、繼承的弊端 繼承作為面向?qū)ο笕筇匦灾?，在給程序設計帶 來巨大便利的同時，也帶來了弊端。例如：1、繼承是侵入性的。只要繼承，就必須擁有父類的所有屬性和方法；2、降低代碼的靈活性。子類必須擁有父類的屬性和方法，讓子類自由的世界中多了些約束；3、增強了耦合性。當父類的常量、變量和方法被修改時，必需要考慮子類的修改，而且在缺乏規(guī)范的環(huán)境下，這種修改可能帶來非常糟糕的結(jié)果大片的代碼需要重構(gòu)。一、繼承的弊端問題：怎樣才能讓繼承機制的“利”大于“弊”？ 引入里氏替換原則二、里氏替換原則的定義1、里氏替換原則通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。子類

3、父類擴展功能改變功能二、里氏替換原則的定義2、里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象。JAVA中：基類稱為父類 ， 導出類稱為子類二、里氏替換原則的定義3、里氏代換原則是實現(xiàn)開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。三、里氏替換原則包含的含義1、子類可以實現(xiàn)父類的抽象方法，但是不能覆蓋父類的非抽象方法 在我們做系統(tǒng)設計時，經(jīng)常會設計

4、接口或抽象類，然后由子類來實現(xiàn)抽象方法，這里使用的其實就是里氏替換原則。子類可以實現(xiàn)父類的抽象方法很好理解，事實上，子類也必須完全實現(xiàn)父類的抽象方法，哪怕寫一個空方法，否則會編譯報錯。三、里氏替換原則包含的含義 里氏替換原則的關鍵點在于不能覆蓋父類的非抽象方法。 父類中凡是已經(jīng)實現(xiàn)好的方法，實際上是在設定一系列的規(guī)范和契約，雖然它不強制要求所有的子類必須遵從這些規(guī)范，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。三、里氏替換原則包含的含義 在面向?qū)ο蟮脑O計思想中，繼承這一特性為系統(tǒng)的設計帶來了極大的便利性，但是由之而來的也潛在著一些風險。

5、所以，子類C1繼承父類C時，可以添加新方法完成新增功能，盡量不要重寫父類C的方法。否則可能帶來難以預料的風險。下面舉例說明：運行結(jié)果：2+1=1三、里氏替換原則包含的含義 上面的運行結(jié)果明顯是錯誤的。類C1繼承C，后來需要增加新功能，類C1并沒有新寫一個方法，而是直接重寫了父類C的func方法，違背里氏替換原則，引用父類的地方并不能透明的使用子類的對象，導致運行結(jié)果出錯。三、里氏替換原則包含的含義2、子類中可以增加自己特有的方法 在繼承父類屬性和方法的同時，每個子類也都可以有自己的個性，在父類的基礎上擴展自己的功能。前面其實已經(jīng)提到，當功能擴展時，子類盡量不要重寫父類的方法，而是另寫一個方法，

6、所以對上面的代碼加以更改，使其符合里氏替換原則。如下例所示： 運行結(jié)果：2-1=1三、里氏替換原則包含的含義3、當子類覆蓋或?qū)崿F(xiàn)父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松HashMap implements MapMap是接口HashMap 是Map的實現(xiàn)類三、里氏替換原則包含的含義 運行結(jié)果：執(zhí)行父類. 注意Son類的func方法前面是不能加Override注解的，因為否則會編譯提示報錯，因為這并不是重寫（Override），而是重載（Overload），因為方法的輸入?yún)?shù)不同。三、里氏替換原則包含的含義4、當子類的方法實現(xiàn)父類的抽象方法時，方法的后置條件（即方

7、法的返回值）要比父類更嚴格執(zhí)行結(jié)果：h=執(zhí)行子類.HashMap implements MapMap是接口HashMap 是Map的實現(xiàn)類四、在使用里氏代換原則時需要注意如下幾個問題1、子類的所有方法必須在父類中聲明，或子類必須實現(xiàn)父類中聲明的所有方法。根據(jù)里氏代換原則，為了保證系統(tǒng)的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。四、在使用里氏代換原則時需要注意如下幾個問題2、我們在運用里氏代換原則時，盡量把父類設計為抽象類或者接口，讓子類繼承父類或?qū)崿F(xiàn)父接口，并實現(xiàn)在父類中聲明的方法，運行時，子類實例替換父類

8、實例，我們可以很方便地擴展系統(tǒng)的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現(xiàn)。里氏代換原則是開閉原則的具體實現(xiàn)手段之一。3、在系統(tǒng)設計時，遵循里氏替換原則，盡量避免子類重寫父類的方法，可以有效降低代碼出錯的可能性。 在Sunny軟件公司開發(fā)的CRM系統(tǒng)中，客戶(Customer)可以分為VIP客戶(VIPCustomer)和普通客戶(CommonCustomer)兩類，系統(tǒng)需要提供一個發(fā)送Email的功能，原始設計方案如圖1所示：圖1原始結(jié)構(gòu)圖 在對系統(tǒng)進行進一步分析后發(fā)現(xiàn)，無論是普通客戶還是VIP客戶，發(fā)送郵件的過程都是相同的，也就是說兩個send()方法中的代碼重復，而且在本系統(tǒng)中還將增加新類型的客戶。為了讓系統(tǒng)具有更好的擴展性，同時減少代碼重復，使用里氏代換原則對其進行重構(gòu)。 在本實例中，可以考慮增加一個新的抽象客戶類Customer，而將CommonCustomer和VIPCustomer類作為其子類，郵件發(fā)送類EmailSender類針對抽象客戶類Customer編程，根據(jù)里氏代換原則，能夠接受基類對象的地方必然能夠接受子類對象