Liskov Substitution Principle
The Liskov Substitution Principle is a software design principle requiring objects of a subtype to be usable wherever objects of its supertype are expected without violating behavioral expectations or program correctness.
Object-Oriented Software Design in C++
The Liskov Substitution Principle states that objects of a subclass should be usable wherever objects of its superclass are expected without violating correctness.
- How it is used
- Guides the design and review of superclass-subclass hierarchies so inherited objects remain safely interchangeable.
- How deep it goes
- Explains substitution, overriding contracts, and a failing CircularBuffer implementation before refactoring toward aggregation.
- Examples
- Uses GeneralTax and LocalTax substitution, then contrasts vector-inherited and vector-contained CircularBuffer implementations.
- What you can do after
- Evaluate subclass designs, preserve overriding contracts, and refactor invalid inheritance toward composition or aggregation.
Read how Object-Oriented Software Design in C++ explains Liskov Substitution Principle →
Go in Action, Second Edition
The Liskov substitution principle states that objects of a subtype should be usable wherever objects of its supertype are expected without invalidating program correctness.
- How it is used
- Uses interfaces to keep domain consumers independent from feed readers, storage systems, and testing implementations.
- How deep it goes
- Explains substitution through Go interfaces, narrowed dependencies, and production-versus-test implementations, without detailing formal behavioral contracts.
- Examples
- Demonstrates Fetcher, Storage, ArticleReader, BoltStore, RSSReader, MockFetcher, and isolated HTTP handler tests.
- What you can do after
- Apply interface substitution to inject production stores, feed readers, mocks, and test doubles without changing consuming packages.
Read how Go in Action, Second Edition explains Liskov Substitution Principle →
Software Design for Python Programmers
The Liskov Substitution Principle is a design principle requiring objects of subclasses to be substitutable for objects of their superclass without invalidating program correctness.
- How it is used
- Guides the design of proper subclasses within object-oriented class hierarchies.
- How deep it goes
- Explains substitution through a failing CircularBuffer example and a refactoring, without developing formal contract rules in detail.
- Examples
- Uses a Python CircularBuffer subclass of list, invalid indexing and pop operations, and a private-list refactoring.
- What you can do after
- Diagnose subclass designs that permit invalid inherited operations and refactor them toward a suitable class relationship.
Read how Software Design for Python Programmers explains Liskov Substitution Principle →
Practices of the Python Pro
The Liskov substitution principle states that objects of a subtype must be replaceable for objects of its supertype without impairing program correctness.
- How it is used
- Checks whether inheritance preserves interchangeable roles and program correctness.
- How deep it goes
- Defines substitution, tests signatures and exceptions, and contrasts inheritance with composition through short Python examples.
- Examples
- Uses Slug and Snail, Bird and Penguin, and a Bicycle model exercise.
- What you can do after
- Diagnose inheritance designs by checking replacement behavior and choosing composition when specialization cannot preserve expectations.
Read how Practices of the Python Pro explains Liskov Substitution Principle →
Functional Design and Architecture: Examples in Haskell
A design principle requiring objects substituted for an abstraction to preserve the behavioral expectations of clients using that abstraction.
- How it is used
- Uses behavioral contracts to keep polymorphic client code unchanged when implementations are substituted.
- How deep it goes
- Explains substitution through an interface and a concrete failure, stopping short of formal contract rules.
- Examples
- Uses ILampSwitcher, DaylightLamp, TableLamp, and a turnAllOff client to demonstrate valid and broken substitution.
- What you can do after
- Diagnose substitution violations by checking whether an implementation preserves the interface behavior clients rely on.
Related concepts
- SOLID principlespart of · The SOLID principles are five object-oriented software-design principles concerning single responsibility, openness to extension, substitutability, interface segregation, and dependency inversion.
- contract testingmeasured by · Contract testing is a software testing technique that verifies whether interacting components conform to an agreed interface, message, or behavioral contract.
- inheritancemeasures · Inheritance is a mechanism by which a child type or element receives properties, values, or behavior from a parent, subject to system rules and possible overrides.
- concrete typecontrasts with · A concrete type is a fully specified, directly implementable or instantiable type with a particular representation and behavior.
- overridecontrasts with · Overriding is defining a more specific implementation that replaces inherited behavior for a type or object while preserving the operation’s interface.
- separation of concernsaddresses · Separation of concerns is a design principle that organizes a system so distinct responsibilities are handled by separate, independently manageable parts.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.