SOLID Principles

# CHAPTER 3

SOLID Principles #

1. Introduction #

2. Learning Objectives #

• Define all five SOLID principles (SRP, OCP, LSP, ISP, DIP).

• Refactor a "God Class" using the Single Responsibility Principle.

• Design extensible systems using the Open/Closed Principle.

• Understand the danger of violating the Liskov Substitution Principle.

• Apply Dependency Inversion to decouple high-level logic from low-level modules.

3. S - Single Responsibility Principle (SRP) #

• The Anti-Pattern: A User class that holds the user's name, connects to the MySQL database to save the user, and sends a "Welcome" email. This class has three responsibilities. If the database changes, or the email API changes, this class must be rewritten.

• The Solution: Split it up. Create a User class (holds data), a UserRepository class (handles the database), and a UserMailer class (handles emails). Now, each class has only one job.

4. O - Open/Closed Principle (OCP) #

• The Anti-Pattern: A ShippingCalculator class with a massive if/else block: if (type == 'ground') return 5; else if (type == 'air') return 20;. Every time you add a new shipping method, you have to modify this existing, tested class, risking breaking old code.

• The Solution: Create a ShippingStrategy interface. Create separate classes GroundShipping and AirShipping that implement the interface. The Calculator just accepts the interface. To add DroneShipping, you write a *new* class. You *extended* the system without *modifying* the Calculator class.

5. L - Liskov Substitution Principle (LSP) #

• The Concept: If Class B extends Class A, you should be able to pass Class B into any function that expects Class A, and the program should not crash or behave weirdly.

• The Anti-Pattern: A Bird class has a fly() method. A Penguin class extends Bird. But penguins can't fly, so the Penguin->fly() method throws an Exception. You have violated LSP, because a Penguin cannot truly substitute a Bird.

• The Solution: Refactor the hierarchy. Create a FlyingBird interface and only have Eagles and Sparrows implement it.

6. I - Interface Segregation Principle (ISP) #

• The Anti-Pattern: A massive Worker interface with work(), eat(), and sleep() methods. A HumanWorker implements it perfectly. A RobotWorker implements it, but is forced to write empty, useless eat() and sleep() methods because robots don't eat.

• The Solution: Break the fat interface into smaller ones: Workable, Eatable, Sleepable. The Human implements all three. The Robot only implements Workable.

7. D - Dependency Inversion Principle (DIP) #

• The Anti-Pattern: A high-level OrderProcessor class directly instantiates a low-level MySQLDatabase class inside its constructor using the new keyword. The OrderProcessor is now permanently glued to MySQL.

• The Solution: The OrderProcessor should accept a DatabaseInterface through its constructor (Dependency Injection). You pass the MySQL class *into* the processor from the outside. Later, you can easily pass in a MongoDBDatabase class instead, and the OrderProcessor won't even notice.

8. Code Examples: Refactoring SRP #

class Invoice {
    public function calculateTotal() { /* Math */ }
    public function printInvoice() { /* HTML Rendering */ }
    public function saveToDatabase() { /* SQL Query */ }
}

*After (Applying SRP):*

class Invoice {
    public function calculateTotal() { /* Math */ }
}
class InvoicePrinter {
    public function print(Invoice $invoice) { /* HTML Rendering */ }
}
class InvoiceRepository {
    public function save(Invoice $invoice) { /* SQL Query */ }
}

9. Best Practices #

• Pragmatism over Dogma: Writing perfectly SOLID code often means creating 5 files instead of 1. For a massive enterprise app, this modularity is mandatory. For a tiny, 100-line script, strictly adhering to SOLID might be massive overkill. Apply the principles where complexity demands it.

10. Mini Project: SOLID Refactoring #

1. 1. The Scenario: You inherit a ReportGenerator class. It fetches data from an API, formats it as JSON, and writes it to a local file. It violates SRP, OCP, and DIP.

1. 2. The Refactor:

• Create a DataFetcher interface (DIP).

• Create a Formatter interface with a format() method. Implement JsonFormatter and XmlFormatter (OCP).

• Create a FileWriter class (SRP).

• Inject these dependencies into the ReportGenerator constructor.

11. Practice Exercises #

1. 1. Define the Single Responsibility Principle (SRP). Why is a class that handles both business logic and database queries a violation of this principle?

1. 2. Explain the Dependency Inversion Principle (DIP). How does "injecting" dependencies via the constructor make a class significantly easier to Unit Test?

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain the Liskov Substitution Principle using the classic "Square/Rectangle" problem. Why does making a Square inherit from a Rectangle often violate LSP?

• Q: What is the Interface Segregation Principle? Walk me through a scenario where forcing a class to implement a "fat" interface leads to bad architectural design.

• Q: How do the SOLID principles directly relate to the Gang of Four Design Patterns? (Hint: Patterns are just standardized implementations of these principles).

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #