DesignPattern系列__04里氏替換原則
1.內容引入——繼承體系的思考
在繼承中,凡是在父類已經實現的方法,其實算是一種契約或者規範,子類不應該在進行更改(重寫);但是,由於這一點不是強制要求,所以當子類進行重寫的時候,就會對繼承體系產生破壞。 同時,繼承帶來便利的時候,也有弊端:給程式帶來了侵入性,增加了物件之間的耦合性,可移植性低。當你修改基類時,子類都需要進行相應的修改。 那麼,如何能夠保持繼承的優點,同時減少缺點對程式的影響呢?也就是我們要討論的主角——“里氏替換原則”。
2.里氏替換原則的定義
1.第一種定義
如果對每一個型別為S的物件o1,都用型別為T的物件o2,使得以T定義的所有程式P在所有的物件o1都替換為o2時,程式P的行為沒有發生變化,那麼型別S是型別T的子型別。
2.第二種定義
所有引用基類的地方都必須能透明地使用其子類進行替換。
第二種型別通俗易懂,就是說,只要父類出現的地方,都應該能用其子類進行替換。 但是反過來卻不一定成立,也就是子類所在的地方替換成父類,是不一定成立的。
根據定義,我們總結出以下幾點:
1.子類必須實現父類定義的抽象方法。對於父類已經實現的非抽象方法,不應該進行重寫。
結合程式碼理解一下:
public abstract class SuperClass {
public abstract void sayHi();
public void doSomething() {
System.out.println("父類被執行..." );
}
//定義一個加法運算函式
public int add(int i,int j) {
int result = i + j;
System.out.println("result = " + result);
return result;
}
}
public class SubClass extends SuperClass {
@Override
public void sayHi() {
System.out.println("子類重寫了父類的sayHi方法..." );
}
//子類特有的方法
public void selfMethod() {
System.out.println("子類特有的方法");
}
//子類重寫了父類的非抽象加法運算方法
@Override
public int add(int i,int j) {
int result = i - j;
System.out.println("result = " + result);
return result;
}
}
public class Client {
public static void main(String[] args) {
SuperClass clazz = new SubClass();
clazz.doSomething();
SubClass subClass = new SubClass();
//子類呼叫自己的方法
subClass.selfMethod();
SuperClass superClass = (SuperClass) subClass;
superClass.add(11,22);
}
}
//執行結果如下:
父類被執行...
子類特有的方法
result = -11
複製程式碼
當你繼承一個基類時,編譯器會要求你來實現基類的抽象方法,否則,會報錯。 但是,對於已經實現的方法,編譯器便不會強制讓你去重寫(也不推薦這樣做):在上面的demo中,子類重寫了父類的add方法,在呼叫時,出現了錯誤(基類定義的加法邏輯,被子類重寫為了一個減法)。這樣子,在父類出現的地方,不能由子類完全替換,違背了“里氏替換原則”。
2.子類可以有自己的方法。
在上面的demo中,子類定義了特有的方法selfMethod(),可以實現其他的業務邏輯。
//子類特有的方法
public void selfMethod() {
System.out.println("子類特有的方法");
}
複製程式碼
3.當子類覆蓋或實現父類的方法時,前置條件(形參)可以比父類方法的輸入引數更寬鬆。
下來看一下demo:
public class Father {
public Collection doSomething(HashMap map) {
System.out.println("父類被執行...");
return map.values();
}
}
public class Son extends Father {
public Collection doSomething(Map map) {
System.out.println("子類被執行...");
return map.values();
}
}
public class Client1 {
public static void main(String[] args) {
invoke();
}
public static void invoke() {
// Father clazz = new Father();
Son clazz = new Son();
HashMap hashMap = new HashMap();
clazz.doSothing(hashMap);
}
//執行結果:父類執行...
複製程式碼
在demo中,基類定義了一個doSomething方法,接受的形參型別為HashMap,子類過載了基類的這個方法,並且將接受的形參型別擴充套件為Map。但是,我們發現,在父類出現的地方,替換為子類後,執行的結果不變。也就是說,子類物件在方法執行時被替換為父類物件,過載的方法並未被執行。如果想要執行子類的方法,就必須重寫,這是正確的。 如果反過來呢?下面通過反證來證明第三點: 當子類的方法中的前置條件比父類小的時候,情況會怎麼樣呢? 在父類和子類中重新定義這兩個方法,符合子類的前置條件小於父類這一條件即可。
//修改父類的方法,前置條件擴大為Map
public Collection doSomething(Map map) {
System.out.println("父類被執行...");
return map.values();
}
//修改子類,前置條件縮小為HashMap
public Collection doSomething(HashMap map) {
System.out.println("子類被執行...");
return map.values();
}
複製程式碼
當客戶端的invoke()方法中,通過Father型別呼叫doSomething方法時,執行結果如下:
//執行結果: 父類執行****
將物件換成Son型別時,執行結果時:
public static void invoke() {
// Father clazz = new Father();
Son clazz = new Son();
HashMap hashMap = new HashMap();
clazz.doSothing(hashMap);
}
//執行結果: 子類被執行...
複製程式碼
我們看到了,子類並沒有重寫父類的方法,但是子類的方法被執行了(這是因為呼叫方法時,優先選擇引數型別一致的方法,也就是過載方法,找不到的話才去找型別為形參的基類的方法),但是,這個現象在邏輯上面是錯誤的。
4.當子類的方法實現父類的抽象方法時,方法的後置條件(即方法的返回值)要比父類更嚴格。
這一點是重寫的要求之一,在這裡就用程式碼展示了。
最佳實踐
在前面的示例中,我們在子類SubClass中不小心重寫了基類SupClass已經實現的方法add(),導致出現了邏輯錯誤。