Liskov Substitution 原则是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 还是我完全搞错了?