若對每個型別 t1 的物件 o1,都存在乙個型別 t2 的物件 o2,使得在所有針對 t2 編寫的程式 p 中,用 o1 替換 o2 後,程式 p 的行為功能不變,則 t1 是 t2 的子型別。簡單的闡述黎克特制替換原則 : 乙個父類a,乙個子類b繼承自a類,在程式**之中可以用子類b的物件引用去替換掉原本**中的a類物件引用,並且程式不會出問題
要滿足這個條件就需要子類a的約束要比父類b更寬鬆,比如父類b中乙個函式訪問修飾符為protected ,在子類a中就需要使用public來定義,不能使用private,因為 private 的訪問控制比 protected 更嚴格
舉乙個例子 :
首先我們判斷乙個繼承是否合理會使用 「is a」 進行判斷,如上圖 :白馬 is a 馬 ,小馬駒 is a 馬 ,看起來沒有問題。
讓我們進一步**,在這個場景中,人能夠騎馬,我們使用白馬來替代馬沒有問題,但是我們使用小馬駒來替代馬時就不行了,因為小馬駒沒長大還不能騎,這樣使用小馬駒繼承馬就違反了黎克特制替換原則。
乙個類如果不是為了被繼承而設計,那麼最好就不要繼承它。粗暴一點地說,如果不是抽象類或者介面,最好不要繼承它。
乙個類,應該只有乙個引起它變化的原因。也就是,乙個類只有乙個職責,如果職責過多,**就會臃腫,可讀性更差,也更難以維護。其實上單一職責原則和介面隔離原則有一定的關係,介面隔離以後,職責就單一了,實現這個介面的類的職責自然也就單一了。但是介面隔離關注的是抽象層,單一職責關注的是兩者兼而有之,偏重於實現。舉乙個例子 :
在上圖中的rectangle類中有draw(畫圖)和area(計算面積)兩個方法,當我們需要進行正方型的面積計算的時候,需要依賴這個類,但是在這個類中又依賴了乙個gui包,讓我們在不需要gui功能的情況下把這個gui包一起打包了,增加負擔,這個類的設計就違反了單一職責原則。
我們將原來的rectangle類進行拆分成兩個類,乙個類只有乙個職責,這樣的設計就滿足了單一職責原則
軟體設計原則 黎克特制替換原則
liskov substitution principle 黎克特制替換原則 定義 如果對每一型別為t1的物件o1,都有型別為t2的物件o2,使得以t1定義的所有程式p在所有的物件o1都替換成o2時,程式p的行為沒有發生變化,那麼型別t2是型別t1的子型別。擴充套件 乙個軟體實體如果適用乙個父類的話...
1 1軟體設計原則 黎克特制替換原則
定義 黎克特制替換原則,所有引用基類的地方必須能透明地使用其子類的物件。定義手槍抽象類 public abstract class abstractgun 定義玩具槍抽象類 public abstract class abstracttoy 實現手槍射擊 public class handgun e...
軟體設計原則之黎克特制替換原則
黎克特制替換原則,在設計模式之禪一書中有兩種定義 綜合上面比較抽象的含義,換句話可能好理解些 其實就是對於同乙個程式p,把出現父類物件的地方,用子類去替換父類物件執行時,程式p功能或者說行為沒有改變,不會產生任何錯誤或異常 但是反過來就不行了,用父類去替換有子類的地方,由於子類可能擴充套件了一些功能...