Collections.unmodifiableXXX 方法是否违反 LSP？ [关闭]

Question

Liskov Substitution principle是SOLID的原则之一。我已经多次阅读这个原则并试图理解它。

这是我的想法，

这个原则与强大的行为契约有关 类的层次结构。子类型应该可以替换为 超类型而不违反合同。

我也读过一些其他的articles，我对这个问题有点迷茫。 Collections.unmodifiableXXX() 方法不违反 LSP 吗？

摘自上面链接的文章：

换句话说，当通过其基类接口使用对象时， 用户只知道基础的前置条件和后置条件 班级。因此，派生对象不能期望这些用户服从 比基类要求的更强大的先决条件

我为什么这么认为？

之前

class SomeClass{
      public List<Integer> list(){
           return new ArrayList<Integer>(); //this is dumb but works
      }
}

之后

class SomeClass{
     public List<Integer> list(){
           return Collections.unmodifiableList(new ArrayList<Integer>()); //change in implementation
     }
}

我无法更改 SomeClass 的实现以在将来返回不可修改的列表。编译将起作用，但如果客户端以某种方式尝试更改返回的 List，那么它将在运行时失败。

这就是 Guava 为集合创建单独的ImmutableXXX 接口的原因吗？

这不是直接违反了 LSP 还是我完全搞错了？

Answer 1

LSP 说每个子类都必须遵守与超类相同的契约。 Collections.unmodifiableXXX() 是否属于这种情况，因此取决于该合同的阅读方式。

Collections.unmodifiableXXX() 返回的对象如果尝试对其调用任何修改方法，则会引发异常。例如，如果调用add()，则会抛出UnsupportedOperationException。

add()的总合约是什么？根据API documentation 是：

确保此集合包含指定的元素（可选 手术）。如果此集合因以下原因而更改，则返回 true 称呼。 （如果此集合不允许重复，则返回 false 并且 已经包含指定的元素。）

如果这是完整的合同，那么确实不能在所有可以使用集合的地方使用不可修改的变体。但是，该规范继续说：

如果集合因任何原因拒绝添加特定元素 除了它已经包含该元素之外，它还必须抛出一个 异常（而不是返回 false）。这保留了不变量 在此之后集合始终包含指定元素 调用返回。

这显式地允许实现具有不将add 的参数添加到集合但导致异常的代码。当然，这包括收集客户的义务，即他们考虑到这种（法律）可能性。

因此，行为子类型（或 LSP）仍然得到满足。 但这表明，如果一个人计划在子类中具有不同的行为，也必须在顶级类的规范中预见到。

顺便说一句，问得好。

Answer 2

是的，我相信你说的没错。本质上，要实现 LSP，您必须能够对子类型执行任何您可以对超类型执行的操作。这也是 LSP 出现椭圆/圆问题的原因。如果 Ellipse 有 setEccentricity 方法，并且 Circle 是 Ellipse 的子类，并且对象应该是可变的，那么 Circle 就无法实现 setEccentricity 方法。因此，你可以用椭圆做一些你不能用圆形做的事情，因此违反了 LSP。† 同样，你可以用普通的 List 做一些你不能用一个包裹的东西做的事情Collections.unmodifiableList，所以这是违反 LSP 的。

问题是这里有一些我们想要的东西（一个不可变的、不可修改的、只读的列表），它没有被类型系统捕获。在 C# 中，您可以使用IEnumerable，它捕获了您可以迭代和读取但不能写入的序列的概念。但是在 Java 中只有List，它通常用于可变列表，但有时我们希望将其用于不可变列表。

现在，有些人可能会说 Circle 可以实现 setEccentricity 并简单地抛出异常，类似地，不可修改的列表（或 Guava 中的不可变列表）在您尝试修改它时会抛出异常。但这并不意味着从 LSP 的角度来看它 is-a List。首先，它至少违反了最小惊喜原则。如果调用者在尝试将项目添加到列表时遇到意外异常，那是相当令人惊讶的。如果调用代码需要采取措施来区分一个它可以修改的列表和一个它不能修改的列表（或者一个它可以设置的偏心率的形状，而一个它不能设置的形状），那么一个就不能真正替代另一个.

如果 Java 类型系统有一个只允许迭代的序列或集合类型，以及另一个允许修改的类型，那就更好了。也许 Iterable 可以用于此，但我怀疑它缺少一些人们真正想要的功能（如size()）。不幸的是，我认为这是当前 Java 集合 API 的限制。

一些人注意到Collection 的文档允许实现从add 方法抛出异常。我想这确实意味着不能修改的列表在涉及add 的合同时遵守法律条文，但我认为应该检查自己的代码，看看有多少地方可以保护调用在争论没有违反 LSP 之前，使用 try/catch 块改变 List 的方法（add、addAll、remove、clear）。也许不是，但这意味着在它作为参数接收的 List 上调用 List.add 的所有代码都已损坏。

这肯定会说很多。

（类似的论点可以表明null 是每个类型的成员的想法也违反了里氏替换原则。）

† 我知道还有其他方法可以解决椭圆/圆问题，例如使它们不可变，或删除 setEccentricity 方法。我在这里只讨论最常见的情况，作为类比。

Answer 3

我不认为这是违规行为，因为合约（即List 接口）说变异操作是可选的。

Answer 4

我认为你没有在这里混合。
来自LSP：

Liskov 的行为子类型概念定义了 可变对象的可替代性；也就是说，如果 S 是 T 的子类型， 那么程序中类型 T 的对象可以替换为 类型 S 而不改变它的任何理想属性 程序（例如，正确性）。

LSP 指的是子类。

List 是一个接口，而不是一个超类。它指定一个类提供的方法列表。但是这种关系不像父类那样耦合。 A 类和 B 类实现相同接口的事实并不能保证这些类的行为。一个实现可以始终返回 true，而另一个实现抛出异常或始终返回 false 或其他任何实现，但两者都遵守接口，因为它们实现了接口的方法，因此调用者可以调用对象上的方法。