反射是否违反 LSP？

Question

来自Liskov Substitution Principle - www.blackwasp.co.uk

不符合 LSP 的一个常见迹象是客户端类检查其依赖项的类型。这可能是通过读取对象的属性来人为地描述其类型或通过使用反射来获取类型。根据依赖的类型，通常会使用 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 支持者认为这是一种反模式，但他们必须这样做，因此他们的框架允许您选择自己的容器。与往常一样，这是一种权衡，它取决于上下文 （您的自己的特定用例）。