Liskov代换原理与接口

Question

是否ICollection

string[] data = new string[] {"a"};
ICollection<string> dataCollection = data;
dataCollection.Add("b");

这导致

未处理的异常：System.集合的大小是固定的。

我发现了一个关于流-实现的非常类似的问题。我打开一个单独的问题，因为这个案例非常不同：Liskov替换原理和流。这里的区别在于，ICollection没有像流-类那样提供CanAdd-属性或类似的东西。




Answer 1

不，因为它不是一个类-接口和实现类之间的关系与超级类和子类之间的关系不同。

LSP特别适用于暗示实现的代码行为——接口并没有实现，所以LSP不适用。

然而，这违反了接口隔离原则，即您应该编写接口以避免未实现的方法。

Answer 2

我明白你为什么这么想。有一个函数需要一个集合，并且它希望集合是可修改的。传递一个数组会使它失败，所以很明显，您不能用这个特定的实现来替代接口，对吗？

这是个问题吗？大概这取决于你期望理想保持多久。你是不是打算用一个数组而不是一个偶然的集合，然后在十年后惊讶于它崩溃了？不是真的。类型系统。NET应用程序的使用并不完美-它没有告诉您这个特定的ICollection

将如果数组不假装实现ICollection，NET可能会更好

但是等等！让我们看一下ICollection的实际合同

[如果…，则引发NotSupportedException]ICollection是只读的。

当您查询IsReadOnly时，数组确实返回true。合同得以维持。

如果您认为Stream不会因为CanWrite而破坏LSP，那么您必须将数组视为有效的集合，因为它们具有IsReadOnly，并且它是true。如果函数接受只读集合并尝试向其添加，则该函数中存在错误。没有办法在C#/中显式地指定它。NET，因此您必须依赖合同的其他部分，而不仅仅是类型-例如，函数的留档应该指定为只读集合抛出NotSupport dExc0019（或ArgumentExc0019或其他任何内容）。一个好的实现应该在函数开始时就做这个测试。

需要注意的一点是，C#中的类型并不像定义LSP的类型理论那样受到约束。例如，您可以在C#中编写这样的函数：

bool IsFrob(object bobicator)
{
  return ((Bob)bobicator).IsFrob;
}

可以bobicator取代任何超类型的对象？显然不是。但这显然不是糟糕的Frobate类型的问题，而是IsFrob函数中的错误。在实践中，C#（和大多数其他语言）中的许多代码只适用于比方法签名中的类型所指示的约束大得多的对象。

对象只有在违反其超类型的约定时才违反LSP。它不能对违反LSP的其他代码负责。通常，您会发现，在LSP下，编写不完美的代码是非常实用的——工程是，而且一直是，关于权衡。仔细权衡成本。