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

【问题标题】：Does Liskov Substitution Principle also apply to classes implementing an interface?Liskov 替换原则是否也适用于实现接口的类？
【发布时间】：2012-10-16 18:49:03
【问题描述】：

LSP 声明类应该可以替代它们的基类，这意味着派生类和基类在语义上应该是等价的。

但是 LSP 也适用于实现接口的类吗？换句话说，如果一个类实现的接口方法在语义上与用户期望的不同，这是否会被视为违反LSP？

谢谢

【问题讨论】：

是的，至少在 java 中是这样。 stackoverflow.com/questions/7072290/…
@Ray Tayek：如果它在 Java 中被视为违规，那么我认为它在 C# 中也是违规？无论如何，你所说的与 Finglas 所说的正好相反——现在我有点困惑
取决于你对en.wikipedia.org/wiki/Subtype_polymorphism的定义
如果一个实现是一个子类型，那么 lsp 对于接口应该是真的
我不是 c# 专家，但我相信在这两种情况下，实现都是子类型。任何实现可能会或可能不会违反 lsp。见en.wikipedia.org/wiki/Circle-ellipse_problem

标签： design-patterns design-principles liskov-substitution-principle

【解决方案1】：

没有

它仅适用于子类型。请参阅Wikipedia article 了解简要摘要。

如果您有一个继承或扩展class A 的class B，您应该能够将class A 切换为class B，并且一切都应该正常工作。接口通常用于不允许多重继承的语言中，因此虽然这两个对象具有共同的行为，但实际执行所述行为的方式在两者之间是不同的，这意味着您不应该能够互换地切换它们。

【讨论】：

1 - “它只适用于子类型。”这是我第一次听说“亚型”这个词。所以（至少在 C# 中）实现接口的类不被视为该接口的子类型？ 2 - 为什么（根据 Ray Tayek 的说法）在 Java 中这会被视为违反 LSP？
术语有点模糊。人们倾向于互换使用子类型/子类。我指的是“是”关系。这就是我对基于继承的 LSP 的看法。然而，听到其他观点会很有趣。无论如何，LSP 只是一个原则。不是规则。在需要的地方应用它。

【解决方案2】：

是的。接口与类一样具有“是[名词]”的关系，只是名词不是具体类型，而是“作为[形容词短语]的事物”。如果形容词短语是“能够被安全地询问它是否可以接受物品，并且能够接受物品或报告它不会”，那么任何不能安全地被问到它是否可以接受物品的对象，或者可能回答是，但如果实际给定一个项目，则表现不佳，将不是由此描述的接口的合法实现。

【讨论】：