3

来自Liskov 替代原则 - 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. 等级制度违反了 Liskov - 那又怎样？

  2. 如何避免违反 Liskov 替换原则 (LSP)？

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

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

  5. GWT 的 ActivityMapper 是否违反了 Liskov 替换原则？

4

1 回答 1

3

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

于 2013-06-19T11:23:42.163 回答