System Design ( Day - 41 )

SOLID Principles | Revision

😩 Why Problems Arise Without SOLID Principles?

Without SOLID, you'll face:

• ❌ Poor maintainability

• ❌ Less readability

• ❌ Higher chances of bugs

• ❌ Tightly coupled classes

• ❌ Difficult testing and refactoring

---

🧱 What is SOLID?

SOLID is an acronym representing 5 principles that help build maintainable and scalable software:

---

🔹 S — Single Responsibility Principle (SRP)

💬 Definition: A class should have only one reason to change.

📺 Analogy: A TV remote should control only the TV — not your AC or refrigerator!

📌 Problem: If a class does multiple things, modifying one part can unintentionally break the others.

🛠️ Solution: Separate responsibilities into their own classes.

javaCopyEdit// ❌ Bad
class Remote {
    controlTV();
    controlAC(); // Not its job
}

// ✅ Good
class TVRemote {
    controlTV();
}

class ACRemote {
    controlAC();
}

---

🔹 O — Open-Closed Principle (OCP)

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

📦 Real-world: Suppose you have a SaveToSQL() method. Tomorrow you want to save data to MongoDB or File too. Don't touch the original logic — just extend it!

🛠️ Solution: Use interfaces and polymorphism to extend behavior.

javaCopyEditabstract class DataSaver {
    abstract void save(Data data);
}

class SaveToSQL extends DataSaver {
    void save(Data data) {
        // Save to SQL
    }
}

class SaveToMongo extends DataSaver {
    void save(Data data) {
        // Save to MongoDB
    }
}

---

🔹 L — Liskov Substitution Principle (LSP)

💬 Definition: Subclasses should be substitutable for their parent classes.

🏦 Example:

• Transaction class has deposit() and withdraw().

• SavingsAccount & CurrentAccount follow both.

• FixedDepositAccount supports only deposit().

❌ Violating LSP:

javaCopyEditclass FixedDeposit extends Transaction {
    void withdraw() {
        throw new UnsupportedOperationException();
    }
}

✅ Solution: Break them into multiple abstract classes:

javaCopyEditabstract class NonWithdrawableAccount {
    abstract void deposit();
}

abstract class WithdrawableAccount extends NonWithdrawableAccount {
    abstract void withdraw();
}

Now inherit WithdrawableAccount in SavingsAccount & CurrentAccount,
and NonWithdrawableAccount in FixedDeposit.

---

🔹 I — Interface Segregation Principle (ISP)

💬 Definition: Clients should not be forced to depend on methods they do not use.

🖨️ Example:

❌ Violating ISP:

javaCopyEditinterface Shape {
    double area();
    double volume(); // Not needed for 2D shapes
}

class Square implements Shape {
    double area() { ... }
    double volume() { throw new UnsupportedOperationException(); }
}

✅ Refactor into segregated interfaces:

javaCopyEditinterface TwoDShape { double area(); }
interface ThreeDShape extends TwoDShape { double volume(); }

class Square implements TwoDShape {
    double area() { ... }
}

class Cube implements ThreeDShape {
    double area() { ... }
    double volume() { ... }
}

🧠 Benefit: Clean, focused contracts.

---

🔹 D — Dependency Inversion Principle (DIP)

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

📧 Example:
High-level class AuthService should not depend directly on EmailSender.

❌ Violation:

javaCopyEditclass AuthService {
    EmailSender sender = new EmailSender();

    void register(User user) {
        sender.sendWelcomeEmail(user.email);
    }
}

✅ Apply DIP:

javaCopyEditinterface MessageSender {
    void send(String to);
}

class EmailSender implements MessageSender {
    public void send(String to) { ... }
}

class AuthService {
    MessageSender sender;

    AuthService(MessageSender sender) {
        this.sender = sender;
    }

    void register(User user) {
        sender.send(user.email);
    }
}

🧠 Benefit: Easily switch between EmailSender, SMSSender, PushNotifier, etc.