Is it considered good practice to declare base interfaces without mutators, supplying mutatators in a sub-interface

Question

I asked a question on StackOverflow on how to properly implement an ImmutableMap that abides by the SOLID principles.

Due to Java's Map interface containing put and putAll, it violates the interface segregation princple by forcing us to implement the put and putAll methods for an ImmutableMap. If we were to define our own interface, it would fall under the code smell category "Alternative Classes with Different Interfaces".

This got me thinking on how would one properly declare an interface that abides by the Liskov Subsitution principle, while still abiding by the interface segregation principle.

The only way I can think of achieving this would to declare the base interface with only accessors, then supply a subinterface with mutators:

interface Map {
    //accessor methods
}

interface MutableMap extends Map {
    //mutator methods
}

class HashMap implements MutableMap {

}

class ImmutableMap implements Map {

}

Is this considered "good practice"? It seems to be the only way to implement immutability while still abiding by the SOLID principles, but I've never heard of such a practice.

Answer 1

Original interface design in the question suggested that Map interface mandated immutability, but this violates Liskov substitution principle. Consider its definition:

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

Consider immutability as the provable property about immutable interface Map. This property (immutability) is clearly not provable in MutableMap interface.

Interface design in the question was clarified and now it doesn't violate Liskov's. Absence of mutate methods alone doesn't mandate immutability.

This more explicit design doesn't violate Liskov's substitution principle:

/** 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)
}

The key here is that immutable interface is not an ancestor of mutable interface, they are both "siblings" who clarify (specialize) constraints/features of the common generic ancestor.

Map interface says nothing about (im)mutability, that's why it's possible to specify this in its descendants without violating Liskov's substitution principle.

Answer 2

No, that is a violation of the Liskov Substitution Principle since you are expanding the implied contract (from immutable to mutable). You could have a Readable foo as the base class, but you need to make extra special care that the code does not imply immutability.