LSP: Liskov 替換原則

在 1988 年， Brabara Liskov 寫下子型態的定義：

若對型態 S 的每一個物件 O₁，都存在一個型態為 T 的物件 O₂，使得在所有針對 T 編寫的程式 P 中，用 O₁ 替換 O₂ 後，程式 P 的行為功能不變，則 S 是 T 的子型態。

指導繼承的使用

此設計符合 LSP，要計算授權費用時，不會以任何方式依賴於他使用的兩個子型態(PersonalLicense, BusinessLicense)，他們都可以替換 License

惡名昭彰的違反 LSP 例子

在這個例子中，正方形不是矩形正確的子型態，因為矩形的長寬獨立，但是正方形卻是要一樣。

以前在數學裡面會說，正方形是矩形的特例，這句話可能就會讓人誤解他是一種子型態

1
2
3
4

Rectangle r = ...
r.setW(5)
r.setH(2)
assert(r.area() == 10)

以上如果給了 r 一個 Square 的類別，後面就會壞掉。

LSP 與架構

最初幾年， LSP 視為指導「繼承的使用」的一種方式，然而現在已經演變成更廣泛的軟體設計原則。

使用者依賴於定義明確的介面，以及依賴於這些介面的實作可替代性

書中舉了一個計程車公司對司機調度服務當做例子，不過我看了多次也還在思考他跟 LSP 的關聯ＸＤ，主要是他假設有一個工程師沒有仔細看 spec 就設計，導致的問題....只是為什麼不仔細看 spec...

低語

但是不論如何，思考到最後，假設像他提的例子，如果兩家業務相同的公司合併，系統上的整合確實存在介面上的不一致。

如果原先的系統沒有做好適當的介面隔離，思考替換實作介面的可能性，那麼整合的工作就會相對變得龐大許多了。

• ← Previous Post
• Next Post →