Author: Daniel

Robert C. Martin, an American software engineer, author and instructor promoted the idea of S.O.L.I.D design principles in Software engineering.

S.O.L.I.D, a set of five software design principles, helps you to write maintainable, scalable (without performance degradation), testable and extendable code (addition of new features/functionality).

The Five S.O.L.I.D Pricinples

1. Single Responsibility principle
2. Open/Closed principle
3. Liskov Substitution principle
4. Interface Segregation principle
5. Dependency Inversion pricinple

1. Single Responsibility Principle

A class must have single responsibility. Imagine you’re building an ecommerce application. The OrderService class handles multiple responsibilities — Order generation, sending emails & invoice generation.

Bad Design

class OrderService {
  createOrder() {
    // Save order to database
  }

  sendEmail() {
    // Send confirmation email
  }

  generateInvoice() {
    // Generate PDF invoice
  }
}

The same can be turned in to single responsibility classes in the following manner. Now each class has a clearly defined responsibility.

Good Design

class OrderService {
  createOrder() {
    // Create order
  }
}

class EmailService {
  sendEmail() {
    // Send confirmation email
  }
}

class InvoiceService {
  generateInvoice() {
    // Generate invoice
  }
}

Why It Matters?

In case the email provider changes, we only need to modify the EmailService class and not the rest.

2. Open/Closed Principle

Software entities must be open for extension and closed for modification. Imagine the same e-commerce Application supports different payment integrations.

Bad Design

class PaymentService {
  pay(method: string) {
    if (method === "stripe") {
      // Stripe payment
    } else if (method === "paypal") {
      // PayPal payment
    }
  }
}

Each time a new payment integration is required, PaymentService must be modified. This is bad design. the same can be turned into the following.

Good Design

interface PaymentGateway {
  pay(amount: number): void;
}

class StripePayment implements PaymentGateway {
  pay(amount: number) {
    console.log("Stripe:", amount);
  }
}

class PayPalPayment implements PaymentGateway {
  pay(amount: number) {
    console.log("PayPal:", amount);
  }
}

class PaymentService {
  constructor(private gateway: PaymentGateway) {}

  process(amount: number) {
    this.gateway.pay(amount);
  }
}

By combining interfaces and single responsible classes, you can then use the classes like below:

const payment = new PaymentService(
  new StripePayment()
);

payment.process(1000);

Why It Matters?

PaymentService doesn’t need to be modified in order to add a new payment gateway provider and is considered closed. The above system is open to the addition of new payment providers.

3. Liskov Substitution Pricinple

Take a look at the following example. A subclass must be usable whenever its parent’s class is expected without breaking the behaviour.

In ReadOnlyStorage, save() is inherited but not fulfilled.

Bad Design

class FileStorage {
  save(file: string) {
    console.log("Saving:", file);
  }
}

class ReadOnlyStorage extends FileStorage {
  save(file: string) {
    throw new Error("Cannot save");
  }
}

Good Design

interface ReadableStorage {
  read(): string;
}

interface WritableStorage {
  save(file: string): void;
}

class CloudStorage
  implements ReadableStorage, WritableStorage {
  read() {
    return "file contents";
  }

  save(file: string) {
    console.log("Saved:", file);
  }
}

class ReadOnlyStorage implements ReadableStorage {
  read() {
    return "file contents";
  }
}

In this case, ReadOnlyStorage fulfils the contract and so is the CloudStorage.

Why It Matters?

The substitutions read() and save() are implemented without breaking the contract.

4. Interface Segregation Principle

Clients (Class, modules or components) should not be forced to depend on methods they don’t use. Look at the following example. When a class implements `Worker`, all methods are forced.

Bad Design

interface Worker {
  code(): void;
  design(): void;
  test(): void;
}

In this case, the contract is forced.

class Developer implements Worker {
  code() {
    console.log("Writing code");
  }

  design() {
    throw new Error("Not supported");
  }

  test() {
    throw new Error("Not supported");
  }
}

Good Design

interface Developer {
  code(): void;
}

interface Designer {
  design(): void;
}

interface Tester {
  test(): void;
}

class FrontendEngineer
  implements Developer, Designer {
  code() {
    console.log("Writing code");
  }

  design() {
    console.log("Designing UI");
  }
}

Why It Matters?

Smaller, focused interfaces reduce unnecessary dependencies and make systems easier to evolve.

Dependency Inversion Pricinple

High-level business logic should depend on abstractions and not on concrete implementations.

Bad Design

class MySQLDatabase {
  save(data: string) {
    console.log("Saved to MySQL");
  }
}

class UserService {
  private db = new MySQLDatabase();

  createUser(name: string) {
    this.db.save(name);
  }
}

You can observe that UserService directly depends on MySQLDatabase which is bad. Also, switching to another service requires changing UserService.

This can be made better in the following manner.

Good Design

interface Database {
  save(data: string): void;
}

class MySQLDatabase implements Database {
  save(data: string) {
    console.log("Saved to MySQL");
  }
}

class PostgresDatabase implements Database {
  save(data: string) {
    console.log("Saved to PostgreSQL");
  }
}

class UserService {
  constructor(private db: Database) {}

  createUser(name: string) {
    this.db.save(name);
  }
}

Look, how switching provider is made possible in the run time based on the requirement.

const db = new PostgresDatabase();

const userService = new UserService(db);

userService.createUser("John");

Why It Matters?

Swapping implementations become easier. So is introducing mocks for unit testing. Also, dependency inversion can reduce coupling between components.

Along with SOLID, you may have heard about KISS (Keep It Short and Simple) and YAGNI (You’re Not Gonna Need It) in Software engineering.