反射是否违反了LSP？

Question

来自Liskov代换原理- www.blackwasp.co.uk

不遵从LSP的一个常见指示是当客户端类检查其依赖项的类型时。这可能是通过读取人工描述其类型的对象的属性，或者通过使用反射获取类型。通常，开关语句将用于根据依赖项的类型执行不同的操作。这种额外的复杂性也违反了开放/封闭原则(OCP)，因为在引入更多的子类时，需要修改客户端类。

以下技术(使用反射)是否会导致违反LSP？

1. 依赖注入
2. 控制反转

注:我来自C#背景。

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

反射；大多数(也许全部？)依赖注入容器在一定程度上依赖于反射--动态检查对象并确定它们的依赖关系。

参考资料：

1. 等级制度违反了Liskov -那又怎样？
2. 如何避免破坏Liskov替换原则(LSP)？
3. Liskov替换原则也适用于实现接口的类吗？
4. 这是否违反了Liskov替代原则，如果是的话，我该怎么办？
5. GWT的ActivityMapper是否违反了Liskov替换原则？

Answer 1

根据我对LSP的理解，它简单地指出，在任何情况下，子类都应该是它们的基类的替代类，也就是说，每当您将基类的实例传递给一个方法、构造函数、服务等时。您应该能够传递子类的一个实例，而无需进行任何代码修改。与任何其他原则一样，LSP是一条指导原则，而不是一条严格的规则，它使我们的代码更易于扩展。当框架编写人员使用反射时，您可以简单地将其与使用服务地点的框架进行对比，后者现在被许多OO支持者认为是反模式，但他们必须这样做，因此他们的框架允许您选择自己的容器。和往常一样，它是一种权衡，它取决于Context (__your自己的特定用例)。