Liskov代换原理、前提和抽象方法

Question

Liskov替代原理（LSP）说：

先决条件不能在子类型中得到加强。

在C#中，我可能违反以下整个原则：

public class A 
{
      public virtual void DoStuff(string text)
      {
            Contract.Requires(!string.IsNullOrEmpty(text));
      }
}

public class B : A
{
      public override void DoStuff(string text)
      {
            Contract.Requires(!string.IsNullOrEmpty(text) && text.Length > 10);
      }
}

但是，如果A.DoStuff是一种abstract方法，会发生什么呢

public class A 
{
      public abstract void DoStuff(string text);
}

public class B : A
{
      public override void DoStuff(string text)
      {
            Contract.Requires(!string.IsNullOrEmpty(text));
      }
}

现在A.DoStuff是无合同的。或者它的合同就是一切允许的。

那么，B. DoStuff前提条件是否违反了Liskov替代原则？

Answer 1

我认为不是。根据定义，抽象方法没有先决条件，因为没有实现。如果实现接口会破坏LSP，这与争论是一样的。

说A. Do某物（）是无契约的是一个不真实的前提。A. Do某物（）是未定义的，因此它不能有超过其签名的契约。

Answer 2

是的，你可以很容易地打破这个原则，不仅仅是在C。

它只指出：

子类型要求：设phi（x）是关于T类型的对象x的可证明属性。那么，对于S类型的对象y，phi（y）应该为真，其中S是T的子类型。

在您的示例中，类型B不满足提供处理短文本的方法DoStuff的属性，尽管它的超类型a满足该属性。所以这个原则被违反了。

程序员应该坚持这个原则。属性也可以是“它做正确的事情”，您可以很容易地通过使用带有错误方法实现的子类型来打破它。

Answer 3

这取决于合同的定义。

LSP是一种理论构造，它不依赖于特定的语言或实现，例如C#的“代码契约”特性。

合同的定义如下：

• 方法名称
• 方法参数名称
• 方法注释
• 返回类型和方法参数类型
• “明确”合同，如合同。需要

最后两个将由编译器验证。然而，前三个也可以是合同的一部分！考虑以下示例：

public interface StuffContainer
{
    void Add(string text);

    // Removes a string that has previously been added.
    void Remove(string text);
}

Remove方法的名称和文档定义了一个明确的先决条件。在实现中验证要删除的字符串之前已添加不会违反LSP。验证字符串是否至少包含5个字符将违反LSP。