Liskov Substitution Principle in LLD - System Design Exercise

Design: Liskov Substitution Principle Demonstration System

In scope: Designing class hierarchies and interfaces to illustrate LSP, testing substitutability. Out of scope: Implementation in specific programming languages, performance optimization, integration with external systems.

Functional Requirements

FR1: Design a system to demonstrate the Liskov Substitution Principle (LSP) in object-oriented design.

FR2: The system should allow substituting derived classes wherever base classes are expected without altering correctness.

FR3: Include examples of classes that follow LSP and classes that violate LSP.

FR4: Provide a way to test or verify that substitutability holds for compliant classes.

FR5: Support clear separation of behaviors to illustrate correct and incorrect inheritance.

Non-Functional Requirements

NFR1: The design must be simple and understandable for beginners.

NFR2: Focus on clarity over complexity; no need for large-scale system.

NFR3: Use standard object-oriented design concepts.

NFR4: Ensure the design can be extended to add more examples of LSP compliance or violation.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Base class or interface defining common behavior

Derived classes implementing or extending base behavior

Test module to verify substitutability

Example classes that violate LSP for contrast

Design Patterns

Inheritance and polymorphism

Interface segregation

Design by contract

Substitutability testing

Reference Architecture

 +---------------------+       +---------------------+       +---------------------+
 |      BaseClass      |<------|   DerivedClassGood   |       |  DerivedClassBad    |
 |  (defines behavior) |       | (follows LSP rules)  |       | (violates LSP rules) |
 +---------------------+       +---------------------+       +---------------------+
           ^                             ^                             ^
           |                             |                             |
           +-----------------------------+-----------------------------+
                                         |
                               +---------------------+
                               |   Substitutability   |
                               |       Tester         |
                               +---------------------+

Components

BaseClass

Abstract class or interface

Defines the common behavior that derived classes must implement or extend.

DerivedClassGood

Concrete class

Implements BaseClass behavior correctly, ensuring substitutability without breaking expectations.

DerivedClassBad

Concrete class

Implements BaseClass but violates LSP by changing expected behavior or throwing unexpected exceptions.

Substitutability Tester

Test module or component

Runs tests to verify that instances of DerivedClassGood can replace BaseClass instances without errors, and detects violations in DerivedClassBad.

Request Flow

1. Client code depends on BaseClass interface or abstract class.

2. Client creates instances of DerivedClassGood or DerivedClassBad but treats them as BaseClass.

3. Substitutability Tester runs operations defined in BaseClass on these instances.

4. For DerivedClassGood, operations succeed and results meet expectations.

5. For DerivedClassBad, operations fail or produce incorrect results, indicating LSP violation.

6. Tester reports compliance or violation based on observed behavior.

Database Schema

Not applicable; this design focuses on class hierarchies and behavior rather than data storage.

Scaling Discussion

Bottlenecks

Adding many derived classes can make testing substitutability complex.

Complex behaviors in derived classes may obscure LSP violations.

Manual testing may miss subtle violations in large hierarchies.

Solutions

Automate substitutability tests with unit testing frameworks.

Use design by contract to specify preconditions and postconditions for methods.

Apply static analysis tools to detect potential LSP violations.

Modularize tests to isolate behavior of each derived class.

Interview Tips

Time: Spend 10 minutes explaining LSP concept and importance, 15 minutes designing class hierarchy and test approach, 10 minutes discussing examples of compliance and violation, 10 minutes on scaling and testing strategies.

Explain LSP as a principle ensuring derived classes can replace base classes without breaking correctness.

Show clear class hierarchy with base and derived classes.

Demonstrate how substitutability is tested.

Discuss examples of both compliance and violation.

Highlight importance of testing and design by contract.

Mention how to scale testing for larger systems.