反射是否违反LSP？

Question

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

不符合LSP的一个常见指示是当客户端类检查其依赖项的类型时。这可以通过读取人为描述其类型的对象的属性或通过使用反射来获得类型。通常，根据依赖项的类型，将使用开关语句执行不同的操作。这种额外的复杂性也违反了打开/关闭原则（OCP），因为随着更多子类的引入，客户端类需要修改。

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

1. 依赖注入

注：我来自C#背景。

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

反射大部分（也许全部？）依赖项注入容器在某种程度上依赖于反射——动态检查对象并确定它们的依赖项。

参考资料：

>

我怎样才能避免违反利斯科夫替换原则（LSP）？

Liskov替换原则是否也适用于实现接口的类？

这是否违反了Liskov替代原则，如果是，我该怎么办？

GWT的ActivityMapper是否违反了Liskov替代原则？

Answer 1

在我理解LSP的方式中，它简单地说明了在任何情况下，子类都应该可以替换它们的基类，也就是说，只要您传递基类的实例（到方法、构造函数、服务等）您应该能够传递子类的一个实例，而无需任何代码修改即可使其工作。和其他原则一样，LSP是一个指导原则，而不是一个严格的规则，它使我们的代码更加开放，便于扩展。当框架编写者使用反射时，他们并没有破坏LSP，您可以简单地将其与使用服务位置的框架进行对比，服务位置现在被许多OO支持者认为是一种反模式，但他们必须这样做，以便他们的框架允许您选择自己的容器。和往常一样，这是一种权衡，取决于上下文（您自己的特定用例）。