在子接口中提供变异器，声明没有变异器的基接口是否被认为是一种良好的做法？

Question

我问了一个关于StackOverflow的问题如何正确地实现一个遵守坚实原则的ImmutableMap。

由于Java的Map接口包含put和putAll，它违背了接口隔离原则，迫使我们为ImmutableMap实现put和putAll方法。如果我们要定义自己的接口，它将属于代码嗅觉类别“具有不同接口的替代类”。

这让我思考如何正确地声明一个符合Liskov代换原则的接口，同时仍然遵守接口隔离原则。

我认为实现这一目标的唯一方法是只使用访问器声明基本接口，然后提供一个带有变异器的子接口：

interface Map {
    //accessor methods
}

interface MutableMap extends Map {
    //mutator methods
}

class HashMap implements MutableMap {

}

class ImmutableMap implements Map {

}

这是否被认为是“良好做法”？这似乎是唯一的方式来实现不变，同时仍然遵守坚实的原则，但我从来没有听说过这样的做法。

Answer 1

最初的界面设计在问题中暗示了Map接口的不可变性，但这违背了Liskov替换原则。考虑其定义：

设Φ(x)是关于T型对象x的一个性质证明，那么Φ(y)对于S类型的对象y是成立的，若S是T的一个子类型。

将不可变性视为不可变接口映射的可证明属性。这个属性(不可变)显然不能在MutableMap接口中证明。

问题中的界面设计被澄清了，现在它并没有违反Liskov的设计，没有变异的方法并不能保证不可变性。

这个更明确的设计并不违反Liskov的替代原则：

/** Contract says nothing about (im)mutability, only that it provides read access */
interface Map {
    // accessor methods
}

/** This specialization explicitly allows mutation */
interface MutableMap extends Map {
    // mutator methods
}

/** This specialization adds an immutability constraint */
interface ImmutableMap extends Map {
    // could contain nothing (just marker interface)
}

这里的关键是，不可变接口不是可变接口的祖先，它们都是阐明(专门化)公共泛型祖先的约束/特性的“兄弟姐妹”。

Map接口没有提到(Im)可变性，这就是为什么可以在不违反Liskov的替换原则的情况下在其后代中指定这一点的原因。

Answer 2

不，这违反了Liskov替代原则，因为您正在扩大隐含合同(从不变到可变)。您可以使用一个Readable foo作为基类，但是您需要特别注意代码并不意味着不可变。