Liskov Substitution Principle (basics)

The LSP is one of the lesser known SOLID principles, but in my opinion, it is crucial to create good types and subtypes.

The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called strong behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address titled Data abstraction and hierarchy. It is based on the concept of “substitutability” — a principle in object-oriented programming stating that an object (such as a class) may be replaced by a sub-object (such as a class that extends the first class) without breaking the program. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. https://en.wikipedia.org/wiki/Liskov_substitution_principle

The above is the definition of the principle, basically what LSP states is that there is a semantic relation between three parts of your code when you are using types and subtypes:

• The client, the part of your code that is using one instance of your hierarchy of types.
• The parent type.
• The subtypes.

The important word here is semantic, because what is saying that word is that the client of your types is going to assume that your parent type will have some properties, apart from the syntax.

That assumption creates a contract between the client and the parent type, but also that contract needs to be valid for all the subtypes created based on that parent type. If the contract is broken by any subtype, then that subtype should not be part of that hierarchy typing structure.

Let’s use an example, I will use contract testing to show what means all of this. Let’s imagine that we have a booking system and at some point of our system we create a BookingRepository interface (the parent type):

And because of my tests, we are going to create two implementations of this repository, one in memory (a fake one for testing) and the other one running against a database (the real one).

What is the semantic relation between these three types and our client?, there are tons of things, but let’s focus just on the simplest one:

• If the client save a Booking with a bookingId then the client will be able to retrieve that booking with the same bookingId.

So let’s create a contract test to check that both implementations fulfill that requirement imposed by the code that uses the parent type (the client):

InMemoryLiskovTest and DBLiskovTest run the same contract to check that they both honor the intentions of the client that use the code based in the parent type.

To allow introducing one or the other implementation in my code, I need to use the parent type, not any of the subtypes. So as my InMemoryBookingRepository need to be introduced in my production code when testing I need to allow my production code to accept InMemoryBookingRepository but also DBBookingRepository when running in production, so it needs to depend on Repository interface (another SOLID principle, Dependency Inversion, depend on abstractions not in concretions).

Imagine that the DBBookingRepository throws an exception when the client tries to save a booking in the database that already exist, the InMemoryBookingRepository doesn’t do that and your client doesn’t expect that. Then you have a bug in your system because you are not honoring Liskov. If your code honor Liskov then you can inject in your code any of these instances and nothing will break.

Imagine that for any reason the client (the production code) needs to check if the instance it has is an object of the type DBBookingRepository to do a special thing, then I’m breaking Liskov principle. If you have to do this in any part of your code, you are not honoring Liskov.

if(repository instanceof DBBookingRepository) {
      // do some DB specific things
} 

You can think of other contracts depending on the usage of your code by your client (production code), all of them need to be true (semantic relationship). Also, you can figure out that I haven’t used inheritance (yes using interfaces is not inheritance), I just created types and subtypes, so this is valid for any language not just for OOP languages.

With these eyes, perhaps it is easier to understand what means the rules under LSP.

The subtype must meet a number of behavioural conditions. These are detailed in a terminology resembling that of design by contract methodology, leading to some restrictions on how contracts can interact with inheritance:

Preconditions cannot be strengthened in the subtype.

Postconditions cannot be weakened in the subtype.

Invariant cannot be weakened in the subtype.

History constraint (the “history rule”). Objects are regarded as being modifiable only through their methods (encapsulation). Because subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. It was the novel element introduced by Liskov and Wing. A violation of this constraint can be exemplified by defining a mutable point as a subtype of an immutable point. This is a violation of the history constraint, because in the history of the immutable point, the state is always the same after creation, so it cannot include the history of a mutable point in general. Fields added to the subtype may however be safely modified because they are not observable through the supertype methods. Thus, one can define a circle with immutable center and mutable radius as a subtype of an immutable point without violating the history constraint. https://en.wikipedia.org/wiki/Liskov_substitution_principle