Liskov Substitution Principle of Object Oriented Design

The Liskov Substitution Principle (LSP) specifies that functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

The Principle

The Liskov Substitution Principle (LSP) can be worded in various ways. The original wording was described by Barbara Liskov as, "If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behaviour of P is unchanged when o1 is substituted for o2 then S is a subtype of T". Robert Cecil Martin's simpler version is, "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it". For languages such as C#, this can be changed to "Code that uses a base class must be able to substitute a subclass without knowing it".

The LSP applies to inheritance hierarchies. It specifies that you should design your classes so that client dependencies can be substituted with subclasses without the client knowing about the change. All subclasses must, therefore, operate in the same manner as their base classes. The specific functionality of the subclass may vary but must conform to the expected behaviour of the base class. To be a true behavioural subtype, the subclass must not only implement the base class's methods and properties but also conform to its implied behaviour. This requires compliance with several rules.

The first rule is that there should be contravariance between parameters of the base class's methods and the matching parameters in subclasses. This means that the parameters in subclasses must either be the same types as those in the base class or must be less restrictive. Similarly, there must be covariance between method return values in the base class and its subclasses. This specifies that the subclass's return types must be the same as, or more restrictive than, the base class's return types.

The next rule concerns pre-conditions and post-conditions. A pre-condition of a class is a rule that must be in place before an action can be taken. For example, before calling a method that reads from a database you may need to satisfy the pre-condition that the database connection is open. Post-conditions describe the state of objects after a process is completed. For example, it may be assumed that the database connection is closed after executing a SQL statement. The LSP states that the pre-conditions of a base class must not be strengthened by a subclass and that post-conditions cannot be weakened in subclasses.

Next the LSP considers invariants. An invariant describes a condition of a process that is true before the process begins and remains true afterwards. For example, a class may include a method that reads text from a file. If the method handles the opening and closing of the file, an invariant may be that the file is not open before the call or afterwards. To comply with the LSP, the invariants of a base class must not be changed by a subclass.

The next rule is the history constraint. By their nature, subclasses include all of the methods and properties of their superclasses. They may also add further members. The history constraint says that new or modified members should not modify the state of an object in a manner that would not be permitted by the base class. For example, if the base class represents an object with a fixed size, the subclass should not permit this size to be modified.

The final LSP rule specifies that a subclass should not throw exceptions that are not thrown by the base class unless they are subtypes of exceptions that may be thrown by the base class.

The preceding rules cannot be controlled by the compiler or limited by object-oriented programming languages. Instead, you must carefully consider the design of class hierarchies and of types that may be subclassed in the future. Failing to do so risks the creation of subclasses that break rules and create bugs in types that are dependent upon them.

One common indication of non-compliance with the LSP is when a client class checks the type of its dependencies. This may be by reading a property of an object that artificially describes its type or by using reflection to obtain the type. Often a switch statement will be used to perform a different action depending on the type of the dependency. This additional complexity also violates the Open / Closed Principle (OCP), since the client class will need to be modified as further subclasses are introduced.

To demonstrate the application of the LSP, we can consider code that violates it and explain how the classes can be refactored to comply with the principle. The following code shows the outline of several classes.