The Liskov Substitution Principle (LSP): Subclasses should be substitutable for their base classes.

This has extensive implications in Design by Contract.
Restated: "The contract of the base class must be honored by the subclass."


Barbara H. Liskov and Stephen N. Zilles, Programming with Abstract Data Types, Computation Structures Group, Memo No 99, MIT, Project MAC, Cambridge Mass, 1974. (See also SIGPLAN notices, 9, 4, pp. 50-59, Apr 1974.)
Robert C. Martin, Engineering Notebook, C++ Report, March, 1996.
Robert C. Martin, Engineering Notebook, C++ Report, Nov-Dec, 1996.

The Liskov Substitution Principle attempts to answer the question: what does it mean to be a subtype. In popular object-oriented languages, subclassing and inheritance is used to achieve many different purposes. One purpose is for reuse of existing code, another purpose is to specify subtype relationship, though both are distinct ideas and are potentially separable. The Liskov Substitution Principle talks about the relationship between subtype and supertype.

The "is a" relationship. Liskov essentially argues that a supertype and a subtype must follow the "is a" relationship. That is, Y is a subtype of Z if Y "is a" Z. For the "is a" relationship to hold, any subtype must be substitutable with its supertype. And for that to work, the subtype must have the same behavior in as the supertype.

Formally, Barabara Liskov stated:

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 behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

Most modern programming languages do not enforce the Liskov Substitution Principle (perhaps excepting Sather). Thus there is usually a distinction between subtype in the normal OO sense, and the stronger "behavioral subtype", which means it is a subtype in the LSP sense.

Reference: Liskov, B. Data Abstraction and Hierarchy. SIGPLAN Notices 23,5, May 1988

Log in or registerto write something here or to contact authors.