若對每個型別 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功能或者說行為沒有改變，不會產生任何錯誤或異常 但是反過來就不行了，用父類去替換有子類的地方，由於子類可能擴充套件了一些功能...