吾所成之事胧砰，不可逆也。
前言
接上篇 iOS 面向?qū)ο罅笤O(shè)計原則（二）開閉原則
正文
里氏代換原則由2008年圖靈獎得主词渤、美國第一位計算機科學(xué)女博士Barbara Liskov教授和卡內(nèi)基·梅隆大學(xué)Jeannette Wing教授于1994年提出猫妙。其嚴(yán)格表述如下：如果對每一個類型為S的對象o1，都有類型為T的對象o2仰税，使得以T定義的所有程序P在所有的對象o1代換o2時构资，程序P的行為沒有變化，那么類型S是類型T的子類型陨簇。這個定義比較拗口且難以理解吐绵，因此我們一般使用它的另一個通俗版定義：
里氏代換原則(Liskov Substitution Principle, LSP)：所有引用基類（父類）的地方必須能透明地使用其子類的對象。
里氏代換原則告訴我們河绽，在軟件中將一個基類對象替換成它的子類對象己单，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立耙饰，如果一個軟件實體使用的是一個子類對象的話纹笼，那么它不一定能夠使用基類對象。例如：我喜歡動物苟跪，那我一定喜歡狗廷痘，因為狗是動物的子類；但是我喜歡狗件已，不能據(jù)此斷定我喜歡動物笋额，因為我并不喜歡老鼠，雖然它也是動物拨齐。
例如有兩個類鳞陨，一個類為BaseClass，另一個是SubClass類，并且SubClass類是BaseClass類的子類厦滤，那么一個方法如果可以接受一個BaseClass類型的基類對象base的話援岩，如：method1(base)，那么它必然可以接受一個BaseClass類型的子類對象sub掏导，method1(sub)能夠正常運行享怀。反過來的代換不成立，如一個方法method2接受BaseClass類型的子類對象sub為參數(shù)：method2(sub)趟咆，那么一般而言不可以有method2(base)添瓷，除非是重載方法。
里氏替換原則是實現(xiàn)開閉原則的重要方式之一值纱。由于使用基類對象的地方都可以使用子類對象鳞贷，因此在程序中盡量使用基類類型來對對象進(jìn)行定義，而在運行時再確定其子類類型虐唠，用子類對象來替換父類對象搀愧。
在使用里氏代換原則時需要注意如下幾個問題：
子類的所有方法必須在父類中聲明，或子類必須實現(xiàn)父類中聲明的所有方法疆偿。根據(jù)里氏代換原則咱筛，為了保證系統(tǒng)的擴展性，在程序中通常使用父類來進(jìn)行定義杆故，如果一個方法只存在子類中迅箩，在父類中不提供相應(yīng)的聲明，則無法在以父類定義的對象中使用該方法处铛。
我們在運用里氏代換原則時饲趋，盡量把父類設(shè)計為抽象類或者接口，讓子類繼承父類或?qū)崿F(xiàn)父接口罢缸，并實現(xiàn)在父類中聲明的方法篙贸，運行時，子類實例替換父類實例枫疆，我們可以很方便地擴展系統(tǒng)的功能，同時無須修改原有子類的代碼敷鸦，增加新的功能可以通過增加一個新的子類來實現(xiàn)息楔。里氏代換原則是開閉原則的具體實現(xiàn)手段之一。
Java語言中扒披，在編譯階段值依，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現(xiàn)無關(guān)的碟案、純語法意義上的檢查愿险，但Java編譯器的檢查是有局限的。OC語言好像不會檢查，OC有動態(tài)語言的特性辆亏，其動態(tài)類型就是在運行的時候才去判斷具體的是哪個類风秤。
小結(jié)
說了那么多，通俗點講：
所有可以使用基類的地方扮叨，一定可以使用子類且不會引入錯誤节榜。
嗯~~還是抽象的描述肥照，那整點具體的。
舉例
在IM通信中，會有消息實體谋右，有的消息是純文本，有的是帶有圖片的蔼夜，有的是帶有鏈接的等判呕。那么把純文本的消息實體Message作為基類，一切從簡磁浇，如下：
- .h
@interface Message : NSObject
@property (nonatomic, copy) NSString *text;
@end
- m
@implementation Message
@end
這時候有個帶圖片的實體刻恭，產(chǎn)品要求，圖片消息里面的文本不能有空格（別問我問什么）扯夭，那么可以整個ImageMessage類鳍贾，如下
- .h
@interface ImageMessage : Message
@property (nonatomic, strong) UIImage *image;
@end
- .m
@implementation ImageMessage
- (void)setText:(NSString *)text {
text = [text stringByReplacingOccurrencesOfString:@" " withString:@""];
super.text = text;
}
@end
就功能而言，這種寫法是滿足產(chǎn)品需求的交洗，但是如果在Message出現(xiàn)的地方骑科，你用ImageMessage替換的話，就會導(dǎo)致用戶不能發(fā)帶有空格的文本了构拳，這就違反了里式替換原則：所有可以使用基類的地方咆爽，一定可以使用子類且不會引入錯誤。
可做以下簡單修改：
- .h
@interface LSPImageMessage : Message
@property (nonatomic, strong) UIImage *image;
/** 去除text內(nèi)空格 */
- (void)checkText;
@end
- .m
@implementation LSPImageMessage
- (void)checkText {
self.text = [self.text stringByReplacingOccurrencesOfString:@" " withString:@""];
}
@end
Demo傳送門
總結(jié)
- 里式替換原則：子類必須完好的（沒有重寫使之功能改變）擁有父類所有方法置森。
里式替換原則是實現(xiàn)開閉原則的必要條件斗埂。要想實現(xiàn)開閉原則，必須遵循里式替換原則凫海，但是實現(xiàn)了開閉原則不一定遵循里式替換原則呛凶。
以下是修改部分，感謝 灬Blue
里氏替換原則是實現(xiàn)開閉原則的重要方式之一行贪。
它避免了繼承中重寫父類造成的可復(fù)用性變差的缺點漾稀。
它是動作正確性的保證。即類的擴展不會給已有的系統(tǒng)引入新的錯誤建瘫，降低了代碼出錯的可能性崭捍。
補充
如果通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單啰脚，但是整個繼承體系的可復(fù)用性會比較差殷蛇，特別是運用多態(tài)比較頻繁時，程序運行出錯的概率會非常大。
如果程序違背了里氏替換原則粒梦，則繼承類的對象在基類出現(xiàn)的地方會出現(xiàn)運行錯誤亮航。這時其修正方法是：取消原來的繼承關(guān)系，重新設(shè)計它們之間的關(guān)系谍倦。
