1. Behavioral Subtyping: Going Beyond Class Inheritance

1.1 Subtypes vs Subclasses

Most modern programming languages enforce subclassing via the compiler's type system. If class B extends class A, the compiler will allow you to pass an instance of B anywhere an instance of A is expected. However, LSP deals with **Behavioral Subtyping**, which goes beyond compilation. Behavioral subtyping requires that class B must not only match class A's method signatures, but also match the **semantic behavior** and expectations of class A's clients.

If a client program expects an object of class A to behave in a certain way (e.g. calling write() on a file writer always writes data to disk), a subclass B (like NullFileWriter, which silently discards data) might satisfy the compiler but violates the client's semantic expectations. If the client fails or behaves incorrectly due to this silent change in behavior, the Liskov Substitution Principle has been violated.

1.2 Semantic Compatibility

LSP compliance ensures that subclasses remain fully compatible with parent abstractions. Without behavioral subtyping, base classes become fragile. Every time a new subclass is added, developers must audit the client modules to ensure they do not crash when interacting with the new type. This undermines the Open-Closed Principle, creating tightly coupled codebases.

Common Misconception — If the code compiles, it obeys LSP: A common misconception is that if code passes static analysis and compiles without errors, it satisfies LSP. In reality, compilers only check method signatures (parameter types and return types). They cannot verify semantic contracts, invariants, or side-effects, which are the core focus of LSP behavioral subtyping.

2. Liskov's Formal Definition: The Mathematical Contract

2.1 The Formal Definition

Barbara Liskov and Jeannette Wing formalized behavioral subtyping mathematically. The definition states: Let $\phi(x)$ be a property provable about objects $x$ of type $T$. Then $\phi(y)$ should be true for objects $y$ of type $S$ where $S$ is a subtype of $T$. This relation is expressed as:

This means that any theorem, assumption, or invariant that holds true for objects of the base type $T$ must also hold true for objects of the subtype $S$. If a client program relies on a property $\phi$ of the parent class, substituting a child object must not invalidate that property. If it does, the substitution fails, and the subclass is not a true behavioral subtype.

3. The Classic Square-Rectangle Dilemma

3.1 Geometric vs Software Invariants

To understand LSP violations, let us look at the classic Square-Rectangle dilemma. In mathematics, a Square is a Rectangle. Therefore, it seems logical to create a class Rectangle with properties width and height, and extend it to create a class Square. To maintain the geometric invariant that a square's sides are always equal, the Square class overrides the setters:

Mermaid Diagram: The inheritance model where Square inherits from Rectangle, setting up a behavioral violation.

Now, consider a client function that takes a Rectangle object, sets its width to 5, sets its height to 10, and asserts that the area is 50 ($5 \times 10 = 50$). If we pass an instance of Rectangle, the assertion succeeds. However, if we substitute a Square object, setting the width to 5 sets both width and height to 5. Setting the height to 10 then overwrites the width to 10. The resulting area is $10 \times 10 = 100$, violating the client's postcondition assertion and crashing the program.

4. Preconditions and Postconditions: The Design by Contract Rules

4.1 Design by Contract (DbC)

LSP behavioral rules are deeply integrated with Bertrand Meyer's **Design by Contract** (DbC) framework. A contract specifies obligations and guarantees between caller and receiver: (1) **Precondition**: requirements that must be true before a method is called. (2) **Postcondition**: guarantees that must be true after the method finishes execution. To obey LSP, a subclass must follow these rules:

• **Preconditions cannot be strengthened**: Subclasses cannot demand more than the parent class. Doing so would break clients that call the method under the parent's weaker assumptions.
• **Postconditions cannot be weakened**: Subclasses cannot guarantee less than the parent. Doing so would fail clients that expect the parent's stronger guarantees.

Mathematically, if $Pre_P$ and $Post_P$ are the preconditions and postconditions of the parent, and $Pre_C$ and $Post_C$ are those of the child, the relationships must satisfy:

Pitfall — Throwing unexpected exceptions: A common way developers violate preconditions/postconditions is by throwing new checked exceptions in overridden methods. If a base class method readData() promises to return a string, throwing a NetworkUnavailableException in a subclass violates the postcondition contract, crashing client code that does not wrap the call in a try-catch block for that specific exception.

5. Covariance and Contravariance: Method Signatures Rules

5.1 Variance of Arguments and Return Types

LSP defines strict rules for type variance when overriding methods in statically typed languages: (1) **Contravariance of Method Arguments**: the method parameters in a subclass must be the same type or a **supertype** of the parameters in the base class. (2) **Covariance of Return Types**: the return value of a subclass method must be the same type or a **subtype** of the return value in the base class.

For example, if a base class has a method process(Dog), a subclass overrides it to accept any Animal (contravariance, accepts a wider range). If a client passes a Dog, the subclass can handle it safely. If the subclass method returned a Terrier (covariance, returns a narrower type) where the parent returned Dog, the client gets a valid Dog object, satisfying expectations.

5.2 Java Generics PECO Rule and C# Variance Keywords

To understand type variance in practice, consider generic containers. Suppose we have a list of subclass objects. Can we pass it to a method expecting a list of parent objects? In Java, the compiler flags this as an error because generics are **invariant** by default. To allow substitution, Java uses wildcard bounds, summarized by the **PECS Rule**: **Producer Covariant, Consumer Contravariant** (or "Producer Extends, Consumer Super"):

• If your generic container acts as a producer (you only read data from it), use covariance: List. This allows passing a list of any subtype of $T$.
• If your generic container acts as a consumer (you only write data to it), use contravariance: List. This allows passing a list of any supertype of $T$.

In C#, developers declare variance directly on interface definitions using keywords out (for covariance, values only exit the interface) and in (for contravariance, values only enter the interface). For example, the standard read-only collection interface is covariant:

This declaration guarantees that the interface is substitution-safe because generic parameters are never consumed as inputs, avoiding runtime type corruption. Below is a variance mapping matrix:

Pitfall — Array Covariance Security Holes: Java arrays are covariant (meaning a String[] array can be cast to an Object[] array). This is a known LSP violation allowed for backward compatibility. If you cast a String[] to Object[] and attempt to write an Integer to it, the compiler checks out fine, but the JVM will throw an ArrayStoreException at runtime, crashing the thread. Always prefer generic collections over raw arrays to prevent these compiler blindspots.

6. Class Invariants: Maintaining Internal Object Consistency

6.1 Preserving State Rules

A **Class Invariant** is a condition that must remain true for every instance of a class throughout its entire lifetime. For example, a BankAccount class might have an invariant that the balance cannot drop below zero. When overriding methods, a subclass must preserve all invariants defined by the parent class. If a subclass method allows the balance to become negative, it violates the parent class invariant, leading to corrupted data structures.

Pitfall — Bypassing Invariant Validation in Constructors: Subclass constructors must pass arguments to the parent constructor to ensure base invariants are validated. If a subclass bypasses the parent's validation checks (e.g., using default values or unvalidated setter overrides during initialization), it can instantiate objects in invalid states, breaking invariants from the start.

7. Advanced: The History Constraint

7.1 Protecting Immutability

The **History Constraint** is the most subtle rule of LSP. It states that subclasses must not introduce new methods that allow modifying state that is immutable in the parent class. If a parent class is designed as an immutable object (e.g. a read-only Point2D containing private coordinates with no setters), a subclass MutablePoint2D that adds setX() and setY() methods violates the history constraint.

Why? Because a client program that accepts Point2D assumes the coordinates are stable and cannot change once initialized. If they pass a MutablePoint2D, the object's state can change unexpectedly elsewhere, violating the assumption of stability and causing bugs.

7.2 Mathematical History constraint and State Transitions

Formally, Liskov and Wing defined history as a sequence of states. Objects are viewed as state machines, where state transitions occur only via executing methods. The **History Constraint** ensures that the state transitions allowed by the subclass are a subset of the state transitions allowed by the parent class. Let $\sigma_i$ and $\sigma_{i+1}$ be two successive states in the history of an object. The history constraint requires that any relation provable between these two states for the parent class $T$ must also hold true for the subtype $S$:

If the parent class lacks any public methods to modify a state variable (meaning the transition $\sigma_i.value \rightarrow \sigma_{i+1}.value$ is restricted to equality $\sigma_i.value = \sigma_{i+1}.value$), the subclass is mathematically forbidden from introducing any method that changes that value. In temporal logic, this is represented as the invariant property that once a state property $P$ is established, it remains true for all future states (represented by the temporal operator $\Box$):

If a subclass introduces a method that breaks this temporal invariant, it violates the history constraint. Below is a comparison table showing how different subtyping operations affect history stability:

Pitfall — Subclassing java.lang.String (Hypothetical): String objects in Java are designed to be immutable. If Java allowed developers to inherit from the String class and create a MutableString subclass, it would cause massive security exploits. Code libraries that check directory access strings would validate a path, only for a background thread to mutate the MutableString contents after validation but before file execution, breaking system safety invariants.

8. Advanced: Refactoring LSP Violations

8.1 Replacing Inheritance with Composition

When inheritance violates LSP, the solution is to refactor. Instead of forcing a subclass relationship, we can: (1) **Introduce a Shared Interface**: extract a common read-only interface that both classes implement, removing the parent-child coupling. (2) **Use Composition Over Inheritance**: make the former subclass contain an instance of the former parent class as a member variable, delegating calls where appropriate.

9. Complete Java Implementation Tracing LSP Violations and Corrections

9.1 The Refactored Setup

The following Java program showcases the Square-Rectangle violation and refactors it into a clean, LSP-compliant model using shared interfaces:

10. Interactive: Liskov Substitution Principle Tester

Click "Step Test" to pass a Rectangle vs a Square to a client test runner. Observe how the Square fails the postcondition assertion check due to setter side-effects:

SOLID compliance impact on Class Coupling

The chart below displays coupling index ratings (lower is better, showing cleaner separation of concerns) across different codebase projects as SOLID compliance increases:

12. Frequently Asked Questions