反射是否違反LSP？

Question

來自非符合LSP的Liskov Substitution Principle - www.blackwasp.co.uk

一個常見的指示是當一個客戶機類檢查其相關性的類型。這可能是通過讀取人爲地描述其類型的對象的屬性或通過使用反射來獲得類型。通常，switch語句將用於根據依賴類型執行不同的操作。這種額外的複雜性也違反了開放/封閉原則（OCP），因爲隨着更多的子類被引入，客戶類將需要被修改。

以下技術（使用反射）是否會導致LSP的違規？

1. 依賴注入
2. 反轉控制

注：我從C＃的背景。

從http://blogs.msdn.com/b/simonince/archive/2008/06/30/dependency-injection-is-dead.aspx

反射;大多數（也許都是？）依賴注入容器在某種程度上依賴於反射 - 動態檢查對象並確定它們的依賴關係。

參考文獻：

1. Hierarchy violates Liskov - so what?

2. How can I avoid breaking Liskov Substitution Principle (LSP)?

3. Does Liskov Substitution Principle also apply to classes implementing an interface?

4. Does this violate the Liskov substitution principle, and if so, what do I do about it?

5. Does GWT's ActivityMapper violate the Liskov Substitution Principle?

Answer 1

的路上我不懂LSP，它只是說，子類應該是替代了在各種情況下它們的基類，那就是隻要你通過基類的實例（一種方法，構造函數，服務等）。您應該能夠傳遞子類的實例，而不用修改任何代碼以使其工作。像任何其他原理一樣，LSP是一個指導原則，而不是一個嚴格的規則，它使我們的代碼更具開放性以實現可擴展性。當框架編寫人員使用反射功能時，他們不會破壞LSP，您可以簡單地使用Service Location與框架進行對比，該框架現在被許多OO支持者認爲是反模式，但他們必須這樣做才能讓框架允許您選擇自己的容器。一如既往，這是一個折衷，它取決於上下文（你的自己的具體使用案例）。