概念：
黎克特制代換原則(liskov substitution principle lsp)物件導向設計的基本原則之一。
黎克特制代換原則中說，任何基類可以出現的地方，子類一定可以出現。
lsp是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，
基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。
黎克特制代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。
而基類與子類的繼承關係就是抽象化的具體實現，所以黎克特制代換原則是對實現抽象化的具體步驟的規範。
我的理解：
關於這個原則，我覺得這是乙個非常抽象的概念。
父類出現的地方，一般子類出現是沒問題的，這是物件導向的保證。
那麼這個原則限制的是什麼呢？限制的是需求層的行為。
物件替換了，得保證行為正常？
這咋保證，能保證嗎？
一般網上會舉這麼乙個反例？
企鵝屬於鳥類，但是企鵝不能飛？
比如有這麼乙個呼叫
移動高度（鳥 麻雀）
移動高度（鳥 企鵝）
那麼這我認為是否符黎克特制替換取決於，在需求的層面上能不能接受，飛離地面一公尺。
入這個飛的動作針對動物的關係系統中，是有飛這個動作，不能飛的動物就抓不到它了。
那麼這個就不符和黎克特制替換的原則了。
而如果飛這個動作表示翅膀的運動，那麼企鵝雖然飛了0公尺高，那麼這也符和黎克特制替換的原則。
那麼在回到對鳥的這個動作的設計之初。
如果對鳥這個概念的設計，包含了飛這個屬性。那麼將企鵝劃入鳥的類別中是沒有問題的。
但是如果對鳥的這個概念的設計，不包含飛，那麼就沒有違背黎克特制替換法則的問題了。
所以這個只是對概念設計的乙個最基本的約束，如果我們對鳥和企鵝的共性最初沒有分析清楚。
談後來是否破壞黎克特制替換原則沒有意義。
如果後來需求真的有變化了了，和最初對鳥和企鵝的設計期待有差別了。
那麼是對鳥和企鵝的最初設計概念發生變化了，不能說物件的設計違背了黎克特制替換原則。
引用文章：黎克特制代換原則
當然，概念的東西，經歷過多次變更，或多人的維護後，一定已經不那麼清晰了。
「黎克特制替換原則」總有被違背的時候，這時候這麼辦呢？
那就得具體問題具體分析了。
針對上面的企鵝問題，如果以能否脫了地面為準，那麼可以定義為企鵝不能飛。讓企鵝的飛丟擲異常。
或者其他的手段。
有時候也可以採用重構的手段使之符和黎克特制替換原則，黎克特制替換本質上不是乙個原則，是bug,不是我們要不要遵守的問題。
而是一旦給原則被破壞我們必須修復的問題。
如果真的有個類不符和黎克特制替換的原則了，這時候我們最好重新分類，建立起新的繼承關係。
或著以依賴，組合的方式來處理 企鵝和鳥的關係。
這是乙個我見到的乙個挺好且清晰的解決思路：設計模式黎克特制替換原則繼承優缺點子類必須完全實現父類的方法
關於黎克特制替換的深入分析
黎克特制代換原則
黎克特制代換原則 liskov substitution principle lsp 物件導向設計的基本原則之一。黎克特制代換原則中說，任何基類可以出現的地方，子類一定可以出現。lsp是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的...
黎克特制代換原則
黎克特制代換原則 黎克特制代換原則 子型別必須能夠替換掉它們的父型別。就是說乙個軟體實體，如果使用的是乙個父類的話，那麼一定適用於其子類，而且，它覺察不出父類物件和子類物件的區別，也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不收到影響時，...
黎克特制代換原則
黎克特制代換原則 子型別必須能替換掉它們的父型別.只有當子類可以替換掉父類，軟體單位的功能不受到影響時，父類才能真正的被復用，而子類也能夠在父類的基礎上增加新的行為.比如說，貓類繼承動物類，動物類擁有吃喝叫跑等行為，當某一天，我們需要狗，牛，羊也擁有類似的行為，由於它們都是繼承於動物，所以除了更改例...