反射是否违反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支持者认为是反模式，但他们必须这样做才能让框架允许您选择自己的容器。一如既往，这是一个折衷，它取决于上下文（你的自己的具体使用案例）。