Collections.unmodifiableXXX方法是否违反LSP？

Question

Liskov替换原理是SOLID的原理之一。我已经读过几次这个原理，并试图理解它。

这就是我的所作所为，

此原则与类层次结构之间的强行为契约有关。子类型应该能够被超类型替换而不会违反合同。

我也读过其他文章，对这个问题我有些失落。难道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文档，它是：

确保此集合包含指定的元素（可选操作）。如果此集合由于调用而更改，则返回true。（如果此集合不允许重复并且已经包含指定的元素，则返回false。）

如果这是一份完整的合同，那么无法修改的变体确实不能在所有可以使用收藏的地方使用。但是，该规范仍在继续，并指出：

如果某个集合由于已经包含该元素以外的其他原因拒绝添加该元素，则它必须引发一个异常（而不是返回false）。这保留了不变，即在此调用返回之后，集合始终包含指定的元素。

这明确允许实现具有不将参数添加add到集合中但导致异常的代码。当然，这包括托收客户有义务考虑到（合法）可能性。

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

好的，顺便问一下。