Single Responsibility (SRP), Open/Close, Liskov’s Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide you every time you write code.
Liskov Substitution Principle (LSP)
Child classes should never break the parent class’ type definitions.
The concept of this principle was introduced by Barbara Liskov in a 1987 conference keynote and later published in a paper together with Jannette Wing in 1994. Their original definition is as follows:
Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
Later on, with the publication of the SOLID principles by Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices and then republished in the C# version of the book Agile Principles, Patterns, and Practices in C#, the definition became known as the Liskov Substitution Principle.
This leads us to the definition given by Robert C. Martin:
Subtypes must be substitutable for their base types.
As simple as that, a subclass should override the parent class’ methods in a way that does not break functionality from a client’s point of view. Here is a simple example to demonstrate the concept.
Given a class
Vehicle – it may be abstract – and two implementations:
A client class should be able to use either of them, if it can use
Which leads us to a simple implementation of the Template Method Design Pattern as we used it in the OCP tutorial.
Based on our previous experience with the Open/Closed Principle, we can conclude that Liskov’s Substitution Principle is in strong relation with OCP. In fact, “a violation of LSP is a latent violation of OCP” (Robert C. Martin), and the Template Method Design Pattern is a classic example of respecting and implementing LSP, which in turn is one of the solutions to respect OCP also.
The Classic Example of LSP Violation
To illustrate this completely, we will go with a classic example because it is highly significant and easily understandable.
We start with a basic geometrical shape, a
Rectangle. It is just a simple data object with setters and getters for
height. Imagine that our application is working and it is already deployed to several clients. Now they need a new feature. They need to be able to manipulate squares.
In real life, in geometry, a square is a particular form of rectangle. So we could try to implement a
Square class that extends a
Rectangle class. It is frequently said that a child class is a parent class, and this expression also conforms to LSP, at least at first sight.
But is a
Square really a
Rectangle in programming?
A square is a rectangle with equal width and height, and we could do a strange implementation like in the above example. We could overwrite both setters to set the height as well as the width. But how would that affect client code?
It is conceivable to have a client class that verifies the rectangle’s area and throws an exception if it is wrong.
Of course we added the above method to our
Rectangle class to provide the area.
And we created a simple test by sending an empty rectangle object to area verifier and the test passes. If our
Square class is correctly defined, sending it to the Client’s
areaVerifier() should not break its functionality. After all, a
Square is a
Rectangle in all mathematical sense. But is our class?
Testing it is very easy and it breaks big time. An exception is thrown to us when we run the test above.
Square class is not a
Rectangle after all. It breaks the laws of geometry. It fails and it violates the Liskov Substitution Principle.
I especially love this example because it not only violates LSP, it also demonstrates that object oriented programming is not about mapping real life to objects. Each object in our program must be an abstraction over a concept. If we try to map one-to-one real objects to programmed objects, we will almost always fail.
LSP taught us why reality can not be represented as a one-to-one relation with programmed objects and how subtypes should respect their parents. We also put it in light of the other principles that we already knew.