# The Liskov Substitution Principle: Subtyping Contracts, Invariants, and History Properties

DevFeed: [The Liskov Substitution Principle: Subtyping Contracts, Invariants, and History Properties](<https://devfeed.tech/articles/the-liskov-substitution-principle-does-more-than-you-think-25507.md>)

Original publisher: [Read original article](<https://buttondown.com/hillelwayne/archive/the-liskov-substitution-principle-does-more-than/>)

Author: Hillel Wayne

Published: 2026-01-06T16:51:26Z

Content type: article

Language: en

Sources: [Newsletter feed for Hillel Wayne's Newsletter](<https://devfeed.tech/sources/newsletter-feed-for-hillel-wayne-s-newsletter.md>)

Topics: [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>)

Tags: [inheritance](<https://devfeed.tech/tags/inheritance.md>), [oop](<https://devfeed.tech/tags/oop.md>), [properties](<https://devfeed.tech/tags/properties.md>), [solid-principles](<https://devfeed.tech/tags/solid-principles.md>), [subtype](<https://devfeed.tech/tags/subtype.md>)

## AI overview

The article explains that the Liskov Substitution Principle is broader than simply treating it as subtyping. It presents requirements involving method preconditions and postconditions, supertype state invariants, and history properties.

## Source excerpt

Happy New Year! I'm done with the newsletter hiatus and am going to try updating weekly again. To ease into things a bit, I'll try to keep posts a little more off the cuff and casual for a while, at least until Logic for Programmers is done. Speaking of which, v0.13 should be out by the end of this month. So for this newsletter I want to talk about the Liskov Substitution Principle (LSP). Last week I read A SOLID Load of Bull by cryptographer Loupe Vaillant, where he argues the SOLID principles of OOP are not worth following. He makes an exception for LSP, but also claims that it's "just subtyping" and further: If I were trying really hard to be negative about the Liskov substitution principle, I would stress that it only applies when inheritance is involved, and inheritance is strongly discouraged anyway. LSP is more interesting than that! In the original paper, A Behavioral Notion of Subtyping, Barbara Liskov and Jeannette Wing start by defining a "correct" subtyping as follows: Subtype Requirement: Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T. From then on, the paper determine what guarantees that a subtype is correct.1 They identify three conditions: Each of the subtype's methods has the same or weaker preconditions and the same or stronger postconditions as the corresponding supertype method.2 The subtype satisfies all state invariants of the supertype. The subtype satisfies all "history properties" of the supertype. 3 e.g. if a supertype has an immutable field, the subtype cannot make it mutable. (Later, Elisa Baniassad and Alexander Summers would realize these are equivalent to "the subtype passes all black-box tests designed for the supertype", which I wrote a little bit more about here.) I want to focus on the first rule about preconditions and postconditions. This refers to the method's contract. For a function f, f.Pre is what must be true going into the function, and