Mastering the SOLID Principles — The Foundation of Clean, Scalable Code

If you want to write cleaner, more maintainable, and scalable software, mastering the SOLID principles is essential. These five core object-oriented design principles empower you to build systems that are easier to understand, extend, and test — without introducing chaos.

Here's a quick breakdown:

S — Single Responsibility Principle (SRP)

Every class or module should have one clear responsibility.

When a class tries to do too many things, it becomes harder to maintain and more prone to bugs.

O — Open/Closed Principle (OCP)

Software should be open for extension, but closed for modification.

You should be able to add new features without rewriting existing code, minimizing the risk of regressions.

L — Liskov Substitution Principle (LSP)

Subtypes must be replaceable for their base types without altering the program’s behavior.

If a subclass breaks the expectations set by the parent class, it violates this principle.

I — Interface Segregation Principle (ISP)

Don't force a class to implement methods it doesn't need.

Instead of one large interface, create smaller, role-specific interfaces.

D — Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules — both should depend on abstractions.

This decouples your code and makes it easier to modify and test.

---

The SOLID principles are foundational guidelines for object-oriented design. They help you create clean, maintainable, and scalable software systems. This guide includes detailed explanations and practical TypeScript examples to illustrate each principle.

S — Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change, meaning it should have a single, well-defined responsibility.

Why It Matters: Mixing responsibilities (e.g., validation and persistence) makes a class fragile—changes to one task can break others. SRP improves modularity and testability.

Violation Example:

// SRP Violating Example
interface Order {
    id: number;
    items: string[];
    total: number;
    customerEmail: string;
}

class OrderProcessor {
    processOrder(order: Order): void {
        if (!order) throw new Error("Order cannot be null");

        // 1. Validate order
        if (order.items.length === 0) {
            throw new Error("Order must have at least one item");
        }

        // 2. Process payment
        console.log(`Processing payment of $${order.total} for order ${order.id}`);

        // 3. Save to database
        console.log(`Saving order ${order.id} with ${order.items.length} items to database`);

        // 4. Send confirmation email
        console.log(`Sending confirmation email to ${order.customerEmail}`);
    }
}

This class handles too much, making it hard to maintain.

Refactored (SRP Applied):

interface Order {
    id: number;
    items: string[];
    total: number;
}

class OrderValidator {
    validate(order: Order): void {
        if (!order) throw new Error("Order cannot be null");
    }
}

class PaymentProcessor {
    processPayment(order: Order): void {
        console.log(`Processing payment for order ${order.id}`);
    }
}

class OrderRepository {
    save(order: Order): void {
        console.log(`Saving order ${order.id} to database`);
    }
}

class EmailNotifier {
    sendConfirmation(order: Order): void {
        console.log(`Sending confirmation email for order ${order.id}`);
    }
}

class OrderProcessor {
    private validator: OrderValidator;
    private paymentProcessor: PaymentProcessor;
    private repository: OrderRepository;
    private notifier: EmailNotifier;

    constructor(
        validator: OrderValidator,
        paymentProcessor: PaymentProcessor,
        repository: OrderRepository,
        notifier: EmailNotifier
    ) {
        this.validator = validator;
        this.paymentProcessor = paymentProcessor;
        this.repository = repository;
        this.notifier = notifier;
    }

    process(order: Order): void {
        this.validator.validate(order);
        this.paymentProcessor.processPayment(order);
        this.repository.save(order);
        this.notifier.sendConfirmation(order);
    }
}

Each class now focuses on one task, enhancing clarity and flexibility.

---

O — Open/Closed Principle (OCP)

Definition: Software entities should be open for extension but closed for modification.

Why It Matters: Modifying existing code risks bugs. OCP allows new functionality via extensions (e.g., interfaces) without altering tested code.

Violation Example:

class InvoicePrinter {
    print(invoice: any, format: string): void {
        if (format === "PDF") {
            // Generate PDF
        } else if (format === "Excel") {
            // Generate Excel
        }
    }
}

Adding a new format requires changing this class.

Refactored (OCP Applied):

interface Invoice {
    id: number;
    amount: number;
}

interface IInvoicePrinter {
    print(invoice: Invoice): void;
}

class PdfInvoicePrinter implements IInvoicePrinter {
    print(invoice: Invoice): void {
        console.log(`Printing PDF invoice for invoice ${invoice.id}`);
    }
}

class ExcelInvoicePrinter implements IInvoicePrinter {
    print(invoice: Invoice): void {
        console.log(`Printing Excel invoice for invoice ${invoice.id}`);
    }
}

class InvoiceService {
    private printer: IInvoicePrinter;

    constructor(printer: IInvoicePrinter) {
        if (!printer) throw new Error("Printer cannot be null");
        this.printer = printer;
    }

    printInvoice(invoice: Invoice): void {
        this.printer.print(invoice);
    }
}

New printers (e.g., HtmlInvoicePrinter) can be added without modifying InvoiceService.

---

L — Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types without altering expected behavior.

Why It Matters: Violating LSP causes errors when subclasses don’t meet the parent’s contract.

Violation Example:

class Vehicle {
    startEngine(): void {
        // Start engine
    }
}

class ElectricCar extends Vehicle {
    startEngine(): void {
        throw new Error("Electric cars don’t have engines!");
    }
}

ElectricCar breaks code expecting startEngine.

Refactored (LSP Respected):

abstract class Vehicle {
    abstract start(): void;
}

interface ICombustionVehicle {
    startEngine(): void;
}

class GasolineCar extends Vehicle implements ICombustionVehicle {
    start(): void {
        this.startEngine();
    }

    startEngine(): void {
        console.log("Gasoline engine started.");
    }
}

class ElectricCar extends Vehicle {
    start(): void {
        console.log("Electric motor activated.");
    }
}

Both subclasses work as Vehicle without issues.

---

I — Interface Segregation Principle (ISP)

Definition: Classes shouldn’t be forced to implement unused interfaces.

Why It Matters: Large interfaces create unnecessary dependencies. ISP favors smaller, specific interfaces.

Violation Example:

interface IWorker {
    work(): void;
    takeBreak(): void;
}

class Robot implements IWorker {
    work(): void {
        console.log("Robot working...");
    }

    takeBreak(): void {
        throw new Error("Robots don’t take breaks!");
    }
}

Robot is forced to implement an irrelevant method.

Refactored (ISP Applied):

interface IWorkable {
    work(): void;
}

interface IBreakable {
    takeBreak(): void;
}

class Human implements IWorkable, IBreakable {
    work(): void {
        console.log("Human working...");
    }

    takeBreak(): void {
        console.log("Human taking a break...");
    }
}

class Robot implements IWorkable {
    work(): void {
        console.log("Robot working...");
    }
}

Robot only implements what it needs.

---

D — Dependency Inversion Principle (DIP)

Definition: High-level modules should depend on abstractions, not low-level details.

Why It Matters: Tight coupling limits flexibility. DIP uses abstractions for loose coupling.

Violation Example:

class Notification {
    private emailService = new EmailService();

    send(message: string): void {
        this.emailService.sendEmail(message);
    }
}

class EmailService {
    sendEmail(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

Notification is tied to EmailService.

Refactored (DIP Applied):

interface IMessageService {
    send(message: string): void;
}

class EmailService implements IMessageService {
    send(message: string): void {
        console.log(`Email sent: ${message}`);
    }
}

class SmsService implements IMessageService {
    send(message: string): void {
        console.log(`SMS sent: ${message}`);
    }
}

class Notification {
    private service: IMessageService;

    constructor(service: IMessageService) {
        if (!service) throw new Error("Service cannot be null");
        this.service = service;
    }

    send(message: string): void {
        this.service.send(message);
    }
}

Notification works with any IMessageService implementation.

Final Thoughts

Applying SOLID in TypeScript yields cleaner, more testable, and adaptable code.