Understanding SOLID Principles in Programming

SOLID is a set of five principles designed to make software more maintainable, scalable, and robust. These principles help developers write cleaner, more efficient code and reduce technical debt. In this article, we will explore each SOLID principle with real-world examples and discuss how programmers can apply them in their projects.

What is SOLID?

The SOLID principles are five design principles introduced by Robert C. Martin (Uncle Bob) that help developers create better object-oriented software. SOLID stands for:

• S - Single Responsibility Principle (SRP)
• O - Open/Closed Principle (OCP)
• L - Liskov Substitution Principle (LSP)
• I - Interface Segregation Principle (ISP)
• D - Dependency Inversion Principle (DIP)

1. Single Responsibility Principle (SRP)

Each class should have only one reason to change, meaning it should have only one job.

Bad Example:

class Report {
          generate() { /* logic to generate report */ }
          print() { /* logic to print report */ }
          saveToFile() { /* logic to save report */ }
      }

The Report class is handling multiple responsibilities (generating, printing, and saving). This violates SRP.

Good Example:

class ReportGenerator { generate() { /* logic */ } }
  class ReportPrinter { print(report) { /* logic */ } }
  class ReportSaver { save(report) { /* logic */ } }

Now, each class has a single responsibility, making the code more modular.

2. Open/Closed Principle (OCP)

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

Bad Example:

class Discount {
      calculate(price, type) {
          if (type === 'Christmas') return price * 0.9;
          else if (type === 'BlackFriday') return price * 0.7;
      }
  }

Every time we add a new discount type, we need to modify the class.

Good Example:

class Discount { calculate(price) { return price; } }
  class ChristmasDiscount extends Discount { calculate(price) { return price * 0.9; } }
  class BlackFridayDiscount extends Discount { calculate(price) { return price * 0.7; } }

Now, we can extend the class without modifying existing code.

3. Liskov Substitution Principle (LSP)

Objects of a superclass should be replaceable with objects of a subclass without affecting functionality.

Bad Example:

class Bird {
      fly() { console.log("Flying..."); }
  }
  class Penguin extends Bird {
      fly() { throw new Error("Penguins can't fly!"); }
  }

Pigeon follows the contract, but Penguin breaks it, violating LSP.

Good Example:

class Bird { }
  class FlyingBird extends Bird { fly() { console.log("Flying..."); } }
  class Penguin extends Bird { swim() { console.log("Swimming..."); } }

Now, we properly separate birds that can and cannot fly.

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

Bad Example:

interface Worker {
      work();
      eat();
  }
  class HumanWorker implements Worker {
      work() { console.log("Working..."); }
      eat() { console.log("Eating..."); }
  }
  class RobotWorker implements Worker {
      work() { console.log("Working..."); }
      eat() { throw new Error("Robots don't eat!"); }
  }

RobotWorker is forced to implement an unnecessary method.

Good Example:

interface Workable { work(); }
  interface Eatable { eat(); }
  
  class HumanWorker implements Workable, Eatable {
      work() { console.log("Working..."); }
      eat() { console.log("Eating..."); }
  }
  class RobotWorker implements Workable {
      work() { console.log("Working..."); }
  }

5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Bad Example:

class MySQLDatabase {
      connect() { console.log("Connecting to MySQL..."); }
  }
  class App {
      constructor() { this.db = new MySQLDatabase(); }
  }

The app is tightly coupled to MySQL.

Good Example:

interface Database { connect(); }
  
  class MySQLDatabase implements Database {
      connect() { console.log("Connecting to MySQL..."); }
  }
  class MongoDB implements Database {
      connect() { console.log("Connecting to MongoDB..."); }
  }
  class App {
      constructor(database) { this.db = database; }
  }

Now, the App class depends on an abstraction (Database), making it flexible.

Conclusion

The SOLID principles provide a strong foundation for writing maintainable and scalable code. By applying these principles, developers can create software that is easier to understand, extend, and debug. Whether you're working on small projects or large-scale systems, following SOLID will help you write cleaner and more efficient code.