🎯 Low Level Design Learning Repository

A comprehensive learning repository for mastering Object-Oriented Programming (OOP) concepts, Class Relationships, and Design Principles through hands-on TypeScript implementations.

---

📚 Table of Contents

• Overview
• Prerequisites
• Getting Started
• Completed Modules
  • OOP Fundamentals
  • Class Relationships
• Project Structure
• Next Steps
• Contributing

---

🎓 Overview

This repository serves as a structured learning path for Low Level Design (LLD) concepts. Each module contains practical implementations, real-world examples, and comprehensive documentation to help you understand and apply OOP principles effectively.

Learning Path

OOP Fundamentals → Class Relationships → Design Principles → Design Patterns
     ✅                ✅                    🔄              📅

---

🛠️ Prerequisites

• Node.js (v16 or higher)
• TypeScript (v5.x)
• Basic understanding of JavaScript/TypeScript
• Familiarity with Object-Oriented Programming concepts

---

🚀 Getting Started

Installation

# Clone the repository
git clone <repository-url>
cd "Low Level Design"

# Install dependencies
npm install

# Run the project
npm run dev

Available Scripts

npm run dev    # Start development server with hot reload
npm run build  # Compile TypeScript to JavaScript
npm start      # Run the compiled JavaScript

---

✅ Completed Modules

1. OOP Fundamentals

📦 Encapsulation

Location: src/encapsulation/

Learn how to properly encapsulate data and behavior within classes.

• Bad Example: BadBankAccount.ts - Demonstrates problems with public fields
• Good Example: GoodBankAccount.ts - Shows proper encapsulation with private fields and controlled access

Key Concepts:

• Private fields and methods
• Public getters/setters
• Data validation
• Business rule enforcement

Example:

// ❌ Bad: Public field allows invalid states
class BadBankAccount {
  balance: number = 0; // Anyone can set this to -1000!
}

// ✅ Good: Encapsulated with validation
class GoodBankAccount {
  private balance: number = 0;

  public deposit(amount: number): void {
    if (amount <= 0) throw new Error("Amount must be positive");
    this.balance += amount;
  }
}

🎭 Abstraction

Location: src/Abstraction/

Understand how to hide implementation details and expose only what's necessary.

• Notification System: NotificationSystem.ts - Interface defining notification contract
• Implementations: EmailNotifier.ts, SMSNotifier.ts - Concrete implementations
• Logger: Logger.ts - Abstraction example for logging

Key Concepts:

• Interface-based design
• Implementation hiding
• Contract definition
• Polymorphism through interfaces

Example:

// Abstraction: What can be done, not how
interface Notifier {
  send(message: string): void;
}

// Implementation: How it's done
class EmailNotifier implements Notifier {
  send(message: string): void {
    console.log(`Sending email: ${message}`);
  }
}

---

2. Class Relationships

This module covers the five fundamental relationships in OOP, demonstrated through practical examples.

🔗 Association

Location: src/Class Relationships/BuildingRiderSystem/entities/RideStrict.ts

Definition: A relationship where two classes are connected but can exist independently.

Real-world Example: In the Ride Booking System, a Ride is associated with a Driver and Rider. They know about each other, but can exist independently.

// Ride knows about Driver (association)
class Ride {
  private driverId?: string; // Associated, not owned

  public assignDriver(driverId: string): void {
    this.driverId = driverId;
  }
}

Key Points:

• Objects can exist independently
• Relationship is temporary or optional
• No ownership implied

---

📦 Aggregation

Location: src/Class Relationships/Aggregation.ts

Definition: A "has-a" relationship where the whole contains parts, but parts can exist without the whole.

Examples:

• Order aggregates Item[] - Items can exist without an Order
• Team aggregates Developer[] - Developers can exist without a Team

// Order aggregates Items (items can exist independently)
class Order {
  private items: Item[] = [];

  public addItem(item: Item): void {
    this.items.push(item); // Item exists independently
  }
}

// Team aggregates Developers
class Team {
  private developers: Developer[] = [];

  public addDeveloper(developer: Developer): void {
    this.developers.push(developer);
  }
}

Key Points:

• "Has-a" relationship
• Parts can exist independently
• Whole doesn't create parts
• Parts can be shared

---

🏗️ Composition

Location: src/Class Relationships/Composition.ts

Definition: A strong "owns-a" relationship where parts cannot exist without the whole.

Example: House composes Room[] - Rooms are created by and owned by the House.

// House composes Rooms (rooms cannot exist without house)
class House {
  private rooms: Room[] = [];

  constructor() {
    // Composition: House CREATES its rooms
    this.rooms = [
      new Room("Living Room"),
      new Room("Kitchen"),
      new Room("Bedroom"),
    ];
  }
}

Key Points:

• "Owns-a" relationship
• Parts are created by the whole
• Parts cannot exist independently
• Lifecycle is tied together

---

🔄 Dependency

Location: src/Class Relationships/BuildingRiderSystem/services/

Definition: A relationship where one class uses another temporarily, often through method parameters.

Example: RideService depends on MatchingService to find drivers.

// RideService depends on MatchingService
class RideService {
  constructor(
    private matchingService: MatchingService // Dependency injection
  ) {}

  requestRide(input: RideInput): Ride {
    // Uses MatchingService temporarily
    const driver = this.matchingService.findNearestDriver(input.pickup);
    // ...
  }
}

Key Points:

• Temporary usage relationship
• Often through method parameters or constructor injection
• No permanent ownership
• Loose coupling

---

⚡ Realization

Location: src/Class Relationships/Realization.ts

Definition: A relationship where a class implements an interface, defining a contract.

Example: Multiple payment methods realize the Payment interface.

// Interface defines the contract
interface Payment {
  pay(amount: number): void;
}

// Classes realize the interface
class CreditCardPayment implements Payment {
  pay(amount: number): void {
    console.log(`Paying ${amount} with credit card`);
  }
}

class PayPalPayment implements Payment {
  pay(amount: number): void {
    console.log(`Paying ${amount} with PayPal`);
  }
}

Key Points:

• "Implements" relationship
• Contract definition through interfaces
• Multiple classes can realize the same interface
• Enables polymorphism

---

3. SOLID Principles

Location: src/SOLID/

✅ S — Single Responsibility Principle (SRP)

Location: src/SOLID/SingleResPrinciple/

What we learned:

• One reason to change: keep each class focused on a single responsibility (persistence vs calculation vs formatting vs delivery).
• Better testing & change isolation: you can change email logic without touching salary calculation (and vice-versa).
• Clean entry point: keep demos/orchestration in a single run...() function and call it from src/index.ts.

Files:

• SRP.ts — Employee entity (data + getters)
• EmpRepo.ts — EmployeeRepository (persistence)
• PaySlipCalc.ts — net pay calculation
• PayslipGen.ts — payslip formatting
• EmailPayslip.ts — email sending
• SRPDemo.ts — orchestration (runSRPDemo())

✅ O — Open/Closed Principle (OCP)

Location: src/SOLID/OpenClosed/

What we learned:

• Open for extension, closed for modification: PaymentProcessor depends on the PaymentMethod interface, so new payment types don’t require editing the processor.
• Add new behavior by adding a class: to support UPI, we add UPIPayment implements PaymentMethod (no if/else, no switch in the processor).
• Important TypeScript pitfall: a .ts file with no imports/exports is treated as a script, which can leak declarations into the global scope.
  • We hit this because src/Class Relationships/Realization.ts defines global CreditCardPayment/PayPalPayment with pay(), while OCP expects processPayment().
  • Fix: in OCP usage files, import concrete implementations from the correct module (./OnlinePayment) so they correctly satisfy PaymentMethod.

Files:

• PaymentMethod.ts — interface/contract
• PaymentProcessor.ts — uses PaymentMethod (stable code)
• OnlinePayment.ts — concrete implementations (CreditCardPayment, PayPalPayment, UPIPayment)
• CheckoutService.ts — demo usage
• WithoutOpenClosed.ts — anti-pattern example (needs modification for new methods)

✅ L — Liskov Substitution Principle (LSP)

Location: src/SOLID/LiskovSubstitution/

What we learned:

• Subtypes must keep promises of supertypes: if code expects a Bird that can fly, every subtype used in that place must really behave like a flying bird.
• Don’t lie with inheritance: avoid child classes that override methods in a way that breaks expectations (e.g. a Penguin that “flies” but actually can’t).
• Model abilities explicitly: split capabilities into more precise types (e.g. Bird vs FlyingBird) so you only use each subtype where it is truly valid.

Files:

• LSP.ts — correct design with Bird, FlyingBird, Sparrow, Penguin
• LSPDemo.ts — story-style demo (runLSPDemo())
• WithoutLSP.ts — anti-pattern example with a non-flying Penguin that still extends Bird

✅ I — Interface Segregation Principle (ISP)

Location: src/SOLID/InterfaceSegregation/

What we learned:

• Small, focused interfaces: give each client only the methods it really needs instead of one giant interface.
• Avoid “fat” interfaces: big interfaces force classes to implement unused methods, leading to fake/empty implementations and confusion.
• Design by role: split abilities into tiny interfaces (CanWalk, CanTalk, CanTakePhoto) and compose them per need (robot dog vs camera toy).

Files:

• ISP.ts — good design with small capability interfaces and RobotDog / CameraToy
• ISPDemo.ts — story-style demo (runISPDemo())
• WithoutISP.ts — anti-pattern with a single SuperToy interface and a bloated implementation

🚗 Comprehensive Example: Ride Booking System

Location: src/Class Relationships/BuildingRiderSystem/

A complete, production-like implementation demonstrating all class relationships in a real-world scenario.

Project Structure

BuildingRiderSystem/
├── entities/              # Domain entities
│   ├── Driver.ts         # Driver entity
│   ├── Rider.ts          # Rider entity
│   ├── RideStrict.ts     # Ride entity (shows Association)
│   ├── RiderEvent.ts     # Event entity (shows Composition)
│   └── PaymentReceipt.ts # Payment receipt
├── services/             # Business logic services
│   ├── RideService.ts    # Main ride orchestration
│   ├── MatchingService.ts # Driver matching logic
│   ├── PricingService.ts # Fare calculation
│   ├── PaymentService.ts # Payment processing
│   └── payments/         # Payment implementations (Realization)
│       ├── CashPayment.ts
│       ├── UPIPayment.ts
│       └── CardPayment.ts
├── repository/           # Data access layer
│   ├── DriverRepository.ts
│   ├── RiderRepository.ts
│   └── RideRepository.ts
├── interfaces/           # Contracts
│   └── PaymentMethod.ts  # Payment interface (Realization)
├── UML/                  # Design documentation
│   ├── 01-UseCaseDiagram.md
│   ├── 02-ClassDiagram.md
│   └── 03-StateDiagram.md
└── ProjectContext.md     # Project requirements and design decisions

Relationships Demonstrated

Relationship	Example	File
Association	Ride ↔ Driver	entities/RideStrict.ts
Aggregation	MatchingService has Driver[]	services/MatchingService.ts
Composition	Ride owns RideEvent[]	entities/RideStrict.ts
Dependency	RideService uses MatchingService	services/RideService.ts
Realization	UPIPayment implements PaymentMethod	services/payments/

Features

• ✅ Complete ride lifecycle (REQUESTED → ACCEPTED → IN_PROGRESS → COMPLETED)
• ✅ Driver matching algorithm
• ✅ Fare calculation
• ✅ Multiple payment methods (polymorphism)
• ✅ State management with validation
• ✅ Repository pattern
• ✅ Service layer architecture
• ✅ UML diagrams

Running the Example

// See src/index.ts for complete example
const ride = rideService.requestRide({
  rideId: "ride-101",
  riderId: rider.getId(),
  pickup: new Location(19.08, 72.88),
  drop: new Location(19.1, 72.9),
});

rideService.startRide(ride.getId());
rideService.completeRide(ride.getId());

const receipt = paymentService.payForRide({
  rideId: ride.getId(),
  durationMin: 18,
  method: new UPIPayment(), // 🔥 Polymorphism in action
});

---

📁 Project Structure

Low Level Design/
├── src/
│   ├── Abstraction/              # Abstraction examples
│   │   ├── NotificationSystem.ts
│   │   ├── EmailNotifier.ts
│   │   ├── SMSNotifier.ts
│   │   └── Logger.ts
│   │
│   ├── Class Relationships/      # Class relationship examples
│   │   ├── Aggregation.ts        # Aggregation examples
│   │   ├── Composition.ts       # Composition examples
│   │   ├── Realization.ts       # Realization examples
│   │   └── BuildingRiderSystem/ # Comprehensive example
│   │       ├── entities/
│   │       ├── services/
│   │       ├── repository/
│   │       ├── interfaces/
│   │       └── UML/
│   │
│   ├── encapsulation/            # Encapsulation examples
│   │   └── BadBankAccount.ts
│   │
│   └── index.ts                  # Main entry point
│
├── package.json
├── tsconfig.json
└── README.md

---

🔜 Next Steps

Design Principles (In Progress)

The next phase will cover SOLID principles and other fundamental design principles:

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)
• DRY (Don't Repeat Yourself)
• KISS (Keep It Simple, Stupid)
• YAGNI (You Aren't Gonna Need It)

Design Patterns (Future)

• Creational Patterns (Factory, Builder, Singleton)
• Structural Patterns (Adapter, Decorator, Facade)
• Behavioral Patterns (Observer, Strategy, Command)

---

🎯 Learning Objectives

By completing this repository, you will:

✅ Understand core OOP concepts (Encapsulation, Abstraction)
✅ Master all five class relationships (Association, Aggregation, Composition, Dependency, Realization)
✅ Apply design principles in real-world scenarios
✅ Build maintainable, scalable, and testable code
✅ Understand when to use each relationship type
✅ Design systems with proper separation of concerns

---

📝 Notes

• All examples are written in TypeScript for type safety and better OOP support
• Code follows production-grade practices with proper error handling
• Each module includes comments explaining the concepts
• The Ride Booking System serves as a comprehensive example combining all concepts

---

🤝 Contributing

This is a personal learning repository. If you find any issues or have suggestions:

1. Create an issue describing the problem or suggestion
2. Fork the repository (if applicable)
3. Make your changes
4. Submit a pull request

---

📄 License

This project is for educational purposes.

---

🙏 Acknowledgments

• Inspired by real-world system design challenges
• Based on industry best practices and design patterns
• Built to understand Low Level Design concepts deeply

---

Happy Learning! 🚀