里氏替換原則,替換的依據(jù)是什么?
前面幾篇文章,我們介紹了 SOLID原則的單一職責(zé)原則和開閉原則,單一職責(zé)描述的模塊需要對(duì)一類行為負(fù)責(zé),開閉原則描述的是對(duì)擴(kuò)展開放,對(duì)修改關(guān)閉。今天我們就來聊聊SOLID的第三個(gè)原則:Liskov替換原則。
什么是里式替換原則?
里式替換原則,Liskov substitution principle(簡稱LSP),它是以作者 Barbara Liskov(一位美國女性計(jì)算機(jī)科學(xué)家,對(duì)編程語言和分布式計(jì)算做出了開創(chuàng)性的貢獻(xiàn),于2008年獲得圖靈獎(jiǎng))的名字命名的,Barbara Liskov 曾在1987年的會(huì)議主題演講“數(shù)據(jù)抽象”中描述了子類型:
Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.
Liskov替換原則的核心:設(shè)Φ(x)是關(guān)于 T類型對(duì)象 x的可證明性質(zhì)。那么對(duì)于 S類型的對(duì)象 y,Φ(y)應(yīng)該為真,其中 S是 T的子類型。
這種科學(xué)的定義是不是過于抽象,太燒腦了?因此,在實(shí)際軟件開發(fā)中的 Liskov替換原則可以這樣:
The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
That requires the objects of your subclasses to behave in the same way as the objects of your superclass.
該原則定義了在不破壞應(yīng)用程序的前提下,超類的對(duì)象應(yīng)該可以被其子類的對(duì)象替換,這就要求子類對(duì)象的行為方式與您的超類對(duì)象相同。
Robert C. Martin 對(duì)SLP的描述更加直接:
Subtypes must be substitutable for their base types.
子類型必須可以替代它們的基本類型。
通過上面幾個(gè)描述,我們可以把 LSP通俗的表達(dá)成:子類型必須能夠替換其父類。
如何實(shí)現(xiàn)Liskov替換原則?
說起 Liskov替換原則的實(shí)現(xiàn),就不得不先看一個(gè)著名的違反 LSP設(shè)計(jì)案例:正方形/長方形問題。盡管這個(gè) case已經(jīng)有點(diǎn)老掉牙,但是為了幫助理解,我們還是炒一次剩飯。
數(shù)學(xué)知識(shí)告訴我們:正方形是一種特殊的長方形,因此用 java代碼分別定義 Rectangle(長方形) 和 Square(正方形)兩個(gè)類,并且 Square繼承 Rectangle,代碼如下:
// Rectangle(長方形)
public class Rectangle {
private int length;
private int width;
public void setLength(double length) {
this.length = length;
}
public void setWidth(double width) {
this.width = width;
}
}
// Square(正方形)
public class Square extends Rectangle {
// 設(shè)置邊長
@Override
public void setLength(double length) {
super.setLength(length);
super.setWidth(length);
}
@Override
public void setWidth(double width) {
super.setLength(width);
super.setWidth(width);
}
}
假設(shè)現(xiàn)在的需求是計(jì)算幾何圖形的面積,因此面積計(jì)算代碼會(huì)如下實(shí)現(xiàn):
// 計(jì)算面積
public int area(){
Rectangle r = new Square();
// 設(shè)置長度
r.setLength(3);
// 設(shè)置寬度
r.setWidth(4);
r.getLength * r.getWidth = 3 * 4 = 12;
// 正方形
Rectangle r = new Rectangle();
// 設(shè)置長度
r.setLength(3); // Length=3, Width=3
// 設(shè)置寬度
r.setWidth(4); // Length=4, Width=4
r.getLength * r.getWidth = 4 * 4 = 16;
}
在這個(gè)例子中,Square類重寫了 setLength和 setWidth方法,以確保正方形的長度和寬度總是相等的。因此:假設(shè) length=3,width=4
- 對(duì)于長方形,面積 = length * width= 3 * 4 = 12,符合預(yù)期;
- 然而,用 Square對(duì)象替換 Rectangle對(duì)象時(shí),程序的行為發(fā)生了變化,本期望矩形的面積為12(3 * 4),但實(shí)際輸出為 4*4=16,違反了里氏替換原則。
如何解決這個(gè) bad case呢?
可以定義一個(gè)幾何圖形的接口,設(shè)定一個(gè)計(jì)算面積的方法,然后長方形、正方形都實(shí)現(xiàn)這個(gè)接口,實(shí)現(xiàn)各自的面積計(jì)算邏輯,整體思路如下:
// 基類
public interface Geometry{
int area();
}
public class Rectangle implements Geometry{
private int length;
private int width;
public int area(){
return length * width;
}
}
public class Square implements Geometry{
private int side;
public int area(){
return side * side;
}
}
我們?cè)賮砜匆粋€(gè) LSP使用的例子:
假設(shè)有一個(gè)股票交易的場景,而且需要支持債券、股票和期權(quán)等不同證券類型的多種交易類型,我們就可以考慮使用 LSP來解決這個(gè)問題。
首先,我們定義一個(gè)交易的基類,并且在基類中定義買入和賣出兩個(gè)方法實(shí)現(xiàn),代碼如下:
// 定義一個(gè)交易類
public class Transaction{
// 買進(jìn)操作
public void buy(String stock, int quantity, float price){
}
// 賣出操作
public void sell(String stock, int quantity, float price){
}
}
接著,定義一個(gè)子類:股票交易,它和基類具有相同的買入和賣出行為,因此,在股票交易子類中需要重寫基類的方法,代碼如下:
// 定義股票交易子類,定義股票特定的買賣動(dòng)作邏輯
public class StockTransaction extends Transaction{
@Override
public void buy(String stock, int quantity, float price){
}
@Override
public void sell(String stock, int quantity, float price){
}
}
同樣,定義一個(gè)子類:基金交易,它和基類具有相同的買入和賣出行為,因此,在基金交易子類中需要重寫基類的方法,代碼如下:
// 定義基金交易子類,定義基金特定的買賣動(dòng)作邏輯
public class FundTransaction extends Transaction{
@Override
public void buy(String stock, int quantity, float price){
}
@Override
public void sell(String stock, int quantity, float price){
}
}
同樣,我們還可以定義了債券交易子類,債券交易和交易基類具有相同的行為:買入和賣出。所以只需要重寫基類的方法,實(shí)現(xiàn)子類特定的實(shí)現(xiàn)就ok了。
// 定義債券交易子類,定義債券特定的買賣動(dòng)作邏輯
public class BondTransaction extends Transaction{
@Override
public void buy(String stock, int quantity, float price){
}
@Override
public void sell(String stock, int quantity, float price){
}
}
上述交易的案例,股票交易和基金交易子類替換基類之后,并沒有破壞基類的買入賣出行為,更具體地說,替換的子類實(shí)例仍提供 buy()和 sell(),可以以相同方式調(diào)用的功能。這個(gè)符合LSP。
經(jīng)過我們的抽象、分離和改造之后,Stock.updateStock()類就穩(wěn)定下來了,再也不需要增加一個(gè)事件然后增加一個(gè)else if分支處理。這種抽象帶來的好處也是很明顯的:每次有新的庫存變更事件,只需要增加一個(gè)實(shí)現(xiàn)類,其他的邏輯都不需要更改,當(dāng)庫存事件無效時(shí)只需要把實(shí)現(xiàn)類刪除即可。
總結(jié)
Liskov替換原則擴(kuò)展了OCP開閉原則,它描述的子類型必須能夠替換其父類型,而不會(huì)破壞應(yīng)用程序。因此,子類需要遵循以下規(guī)則:
- 不要對(duì)輸入?yún)?shù)實(shí)施比父類實(shí)施更嚴(yán)格的驗(yàn)證規(guī)則。
- 至少對(duì)父類應(yīng)用的所有輸出參數(shù)應(yīng)用相同的規(guī)則。
Liskov替換原則相對(duì)前面的單一職責(zé)和開閉原則稍微晦澀一些,因此在開發(fā)中容易誤用,因此我們特別要注意類之間是否存在繼承關(guān)系。
LSP不僅可以用在類關(guān)系上,也可以應(yīng)用在接口設(shè)計(jì)中。