LSP (Liskov Substitution Principle) 簡單的說就是：子類別必須能取代父類別。
我在寫Class與Instance的本質時忘了這叫什麼（又不是考試，誰會記得啥Liskov），但依我十多年C++的經驗，遵守LSP才會讓程式的責任歸屬分明。Agile PPP這本書舉的例子是Rectangle與Square，我就不細說。舉個好懂的例子(但設計得很差，臨時想不到好例子)：Employee，Employee是class，而AEmployee是A公司用的Employee子類別。設計Employee的人當初有一個store的method，但AEmployee是存在SQLServer，因此store就傳回false。結果在A公司專案的主系統呼叫到store時，就發生錯誤。明眼人一看就知道，應該把Employee設計成介面，並且把Business與Data分開，這個就不談。
我的意思是：違反LSP確實很危險，在大型專案不注意就會產生奇怪的錯誤。設計子類別時一定要遵守LSP，若一定會違反，則要改變設計，這個時候應該要優先考慮：組合/聚合重複使用原則(Composition/Aggregation Principle ; CARP)
CARP比較簡單，就是儘量使用合成/聚合，少用繼承。能夠用HAS-A就不要用IS-A。
我在寫Class與Instance的本質時忘了這叫什麼（又不是考試，誰會記得啥Liskov），但依我十多年C++的經驗，遵守LSP才會讓程式的責任歸屬分明。Agile PPP這本書舉的例子是Rectangle與Square，我就不細說。舉個好懂的例子(但設計得很差，臨時想不到好例子)：Employee，Employee是class，而AEmployee是A公司用的Employee子類別。設計Employee的人當初有一個store的method，但AEmployee是存在SQLServer，因此store就傳回false。結果在A公司專案的主系統呼叫到store時，就發生錯誤。明眼人一看就知道，應該把Employee設計成介面，並且把Business與Data分開，這個就不談。
我的意思是：違反LSP確實很危險，在大型專案不注意就會產生奇怪的錯誤。設計子類別時一定要遵守LSP，若一定會違反，則要改變設計，這個時候應該要優先考慮：組合/聚合重複使用原則(Composition/Aggregation Principle ; CARP)
CARP比較簡單，就是儘量使用合成/聚合，少用繼承。能夠用HAS-A就不要用IS-A。
留言