What does it mean when we break the principle?

Java has an immutable List<T> that extends from List<T>, but throws an exception when you try to call add (or any other method that would mutate the list). Does this mean that the immutable list isn’t a subtype of List, it just happens to inherit from List?

(Disclaimer: I will purposefully conflate subtyping and inheritance, because this is what most programmers are used to.)

The Liskov’s substitution principle isn’t something you can choose to violate. It holds whether you want it or not, because it’s a tautology, and an obvious one at that:

Let S be a subtype of T. If P(x) is a property that holds whenever x is a value of type T, then P(x) also holds whenever x is a value of type S.

So what’s the problem? When the LSP seems not to hold, what’s actually happening is that your types don’t mean what you think they mean. For example, if a class X has an overridable method foo(), then whatever happens in the internal implementation of X.foo() is NOT the definitive semantics of X.foo(). Instead, the correct meaning is that anything could happen at all.

You can make the meaning of X.foo() more precise by controlling who’s allowed to inherit from X. For example, if X belongs to a package P and your language allows you to prevent classes outside of P from inheriting from X, then, from the point of view of a user of P, the meaning of X.foo() is completely determined by the set of classes in P that do, in fact, inherit from X.

But, since the set of classes in P that inherit from X is completely known to P‘s author, wouldn’t it be simpler and better to turn X into a sum type, and turn X’s subclasses into the constructors of this sum?

All the various various cases can all be explained with variance.

• If you modify a precondition, that’s input, so it needs to be contravariant (e.g., you can only lift restrictions, not add new ones);
• If you modify a postcondition / invariant, that’s output, so it needs to be covariant (e.g., you can only add new restrictions, not lift older ones).

There are cases that can’t be explained by function signatures alone, but that’s because, when you have state, those functions depend on each other, so classes have protocols of utilization.

For example:

 interface Iterator<A> {
   boolean hasNext();
   A getNext();
 }

Let’s say that we invent a new interface:

 interface DisposableIterator<A> extends Iterator<A> {
   boolean hasNext();
   A getNext();
   void dispose();
 }

This breaks the “Liskov substitution principle” because hasNext and next are no longer the only methods you need to care about to operate Iterator. And if you don’t use dispose, you’ll probably have a resource leak. Therefore all functions working on Iterator are buggy when used with a DisposableIterator.

This is astonishing if true. It is extremely restrictive on the valid subtypes. For example ButtonWithRedBorder cannot be a subtype of Button! That means essentially every GUI library is Liskov-violating. By contrast, Button and ButtonWithRedBorder can both be implementations of ButtonInterface. Perhaps this explains why I’ve always found it much more satisfactory to designing programs using type classes than objects.

Under “The fix” you are testing whether WrappedCounter is a subtype of Counter. But earlier wasn’t it the other way around?

Wouldn’t both the “invariant rule” and the “history rule” follow from the pre- and post-condition rules if we treat mutable state as input/output (as in Haskell)?

SOLID is a stupid idea. Especially the L part. Apparently someone was looking for what an L can stand for to have a nice abbr. Think, have you ever worked on something what does not comply with this “principle”?