A Behavioral Notion of Subtyping.¶
Liskov, B. H., & Wing, J. M. (1994). A Behavioral Notion of Subtyping. ACM Transactions on Programming Languages and Systems, 16(6), 1811-1841.
Cited by¶
9 citations across 9 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Fungibility
- And in software design, interface-conforming objects are fungible at the call site, with the Liskov substitution principle serving as fungibility-as-correctness criterion and type abstraction as the fungibilizing mechanism.
This sourceFormalizes the Liskov substitution principle — any implementation of a type substitutes for any other without breaking the caller — fungibility as a correctness criterion.
Supported in partVerified against the publisher's abstract
The paper's own abstract states that a subtype must preserve any property proved of its supertype, which underwrites substitutability-as-correctness, but it says nothing of type abstraction as a fungibilizing mechanism.
“This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects.”
- And in software design, interface-conforming objects are fungible at the call site, with the Liskov substitution principle serving as fungibility-as-correctness criterion and type abstraction as the fungibilizing mechanism.
- Inheritance
- The three load-bearing commitments are these. Lineage: a directed, asymmetric relation between a parent and a derivative — child class and superclass, descendant and ancestor, heir and decedent, subspecies and species, statute and constitutional predecessor. Default carrying-over: by default the properties of the parent apply to the derivative without re-derivation — a child class gets its parent's methods, a beneficiary gets the testator's estate, an organism gets its parents' alleles, a junior court gets binding precedent.
This sourceFormal statement of the substitutability principle (LSP): a subtype must be usable wherever its supertype is expected.
Supported in partVerified against the publisher's abstract
Abstract gives the behavioural form of carrying-over for sub/supertypes, backing the child-class instance only, not the estate, allele or precedent instances.
“This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects.”
- The three load-bearing commitments are these. Lineage: a directed, asymmetric relation between a parent and a derivative — child class and superclass, descendant and ancestor, heir and decedent, subspecies and species, statute and constitutional predecessor. Default carrying-over: by default the properties of the parent apply to the derivative without re-derivation — a child class gets its parent's methods, a beneficiary gets the testator's estate, an organism gets its parents' alleles, a junior court gets binding precedent.
- Substitutability
- A substitutable component conforms to an interface or specification such that swapping it for another conforming component preserves system performance within acceptable bounds, a relation Liskov and Wing (1994) made precise as behavioral subtyping: a subtype is substitutable for its supertype only when every property provable of the supertype remains true of the subtype.
This sourceFormal definition of behavioral subtyping (the Liskov Substitution Principle): a subtype S of T is substitutable for T iff every property provable of T-objects also holds of S-objects, making interface conformance a precise guarantee of swap-safety.
Supported in partVerified against the publisher's abstract
The abstract states the behavioral-subtyping condition (properties proved of supertype objects must hold for subtype objects) but says nothing about preserving system performance.
“This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects.”
- A substitutable component conforms to an interface or specification such that swapping it for another conforming component preserves system performance within acceptable bounds, a relation Liskov and Wing (1994) made precise as behavioral subtyping: a subtype is substitutable for its supertype only when every property provable of the supertype remains true of the subtype.
Domain-specific¶
- Liskov Substitution Principle
- The Liskov Substitution Principle (LSP; Barbara Liskov 1987, formalised with Jeannette Wing in 1994) states the contractual condition under which a subtype can correctly replace its supertype in a typed object-oriented program: if S is a declared subtype of T, then substituting an instance of S for an instance of T must leave the behaviour of any client program written against T's interface unchanged
Supported in partVerified against the source
- The Liskov Substitution Principle (LSP; Barbara Liskov 1987, formalised with Jeannette Wing in 1994) states the contractual condition under which a subtype can correctly replace its supertype in a typed object-oriented program: if S is a declared subtype of T, then substituting an instance of S for an instance of T must leave the behaviour of any client program written against T's interface unchanged
- Refused Bequest
- The structural commitment that makes this a failure rather than a mere style choice is the Liskov Substitution Principle: a correctly formed subclass must be substitutable for its supertype everywhere the supertype is used, without breaking the contract clients depend on.
This sourceThe formal behavioural-subtyping requirement that subtype objects must satisfy every property provable of the supertype, so clients cannot tell them apart.
SupportedVerified against the source
- The structural commitment that makes this a failure rather than a mere style choice is the Liskov Substitution Principle: a correctly formed subclass must be substitutable for its supertype everywhere the supertype is used, without breaking the contract clients depend on.
Mechanisms¶
- Black-Box Contract Test Suite
- This is the Liskov Substitution Principle made runnable: a replacement must be usable everywhere the type is expected, and the suite is where that is checked.
This sourceDefines behavioral subtyping so properties proved about supertype objects continue to hold for subtype objects used in their place.
- This is the Liskov Substitution Principle made runnable: a replacement must be usable everywhere the type is expected, and the suite is where that is checked.
- Dependency Injection or Plugin Slot
- Its honest limitation is that a stable signature is not behavioral equivalence: a plugged implementation can satisfy every method and still break a caller's unstated expectations — a Liskov Substitution Principle violation.
This sourceDefines behavioral subtyping so a subtype must preserve the behavior expected of the supertype, not merely share an interface or method signatures.
- Its honest limitation is that a stable signature is not behavioral equivalence: a plugged implementation can satisfy every method and still break a caller's unstated expectations — a Liskov Substitution Principle violation.
- Object-Oriented Class Inheritance
- The long-standing discipline is to favor composition over inheritance: reach for inheritance only for true subtype relationships, honor the base contract in every override (the Liskov Substitution Principle), and seal what must not be overridden.
This sourceDefines behavioral subtyping so that every property proved for supertype objects remains true of subtype objects, preserving substitutability.
- The long-standing discipline is to favor composition over inheritance: reach for inheritance only for true subtype relationships, honor the base contract in every override (the Liskov Substitution Principle), and seal what must not be overridden.
- Schema Extension and Override Check
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 5 of 9 citations: 1 supported, 4 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:171b777c947e · see in the full table