Which statement best describes the Liskov Substitution Principle in object-oriented design?

Which statement best describes the Liskov Substitution Principle in object-oriented design?

• A. Subclasses must be substitutable for their base classes without altering correctness
• B. Subclasses should be stricter than their base classes
• C. Subclasses can override methods without any constraints
• D. Subclasses must be sealed and immutable

Answer: (A)

The idea being tested is that you should be able to use a subclass wherever a base class is expected, without breaking the program’s correctness. Subclasses must honor the contract of their base class so that code written for the base type remains valid when it encounters the subclass. In practice, this means a subclass should not require stronger preconditions for its methods, and it should not weaken the postconditions or change the outcomes that the base class promises. It should preserve the base class’s invariants and behavior; callers should not need to know they are dealing with a subclass. If a method in the base class guarantees a certain result, the subclass’ override should guarantee the same result (or something that aligns with the base contract). Also, introducing new exceptions or failure modes that the base type didn’t specify can break substitutability. An easy way to visualize it: code that works with the base type should continue to work with the subclass without any special handling or surprises. If a subclass makes it impossible to substitute it for the base class in existing client code, that’s a sign it’s not adhering to this principle. The other options miss this essential idea: one suggests being stricter than the base class, which breaks substitutability; another allows overrides with no constraints, which risks violating the base contract; and another focuses on sealing or immutability, which is a design choice rather than about substitutability.

The idea being tested is that you should be able to use a subclass wherever a base class is expected, without breaking the program’s correctness. Subclasses must honor the contract of their base class so that code written for the base type remains valid when it encounters the subclass.

In practice, this means a subclass should not require stronger preconditions for its methods, and it should not weaken the postconditions or change the outcomes that the base class promises. It should preserve the base class’s invariants and behavior; callers should not need to know they are dealing with a subclass. If a method in the base class guarantees a certain result, the subclass’ override should guarantee the same result (or something that aligns with the base contract). Also, introducing new exceptions or failure modes that the base type didn’t specify can break substitutability.

An easy way to visualize it: code that works with the base type should continue to work with the subclass without any special handling or surprises. If a subclass makes it impossible to substitute it for the base class in existing client code, that’s a sign it’s not adhering to this principle.

The other options miss this essential idea: one suggests being stricter than the base class, which breaks substitutability; another allows overrides with no constraints, which risks violating the base contract; and another focuses on sealing or immutability, which is a design choice rather than about substitutability.