相关疑难解决方法(0)

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或我完全弄错了吗？