SOLID Principles for Software Architecture

Introduction to SOLID

SOLID is an acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. These principles are a cornerstone of object-oriented design and are widely adopted in the software development community to create robust and scalable applications.

Adhering to SOLID principles can significantly reduce the complexity of your codebase, making it easier to refactor, extend, and debug over time. They guide developers in creating loosely coupled systems where components can be modified or replaced with minimal impact on other parts of the system.

The Five SOLID Principles

S - Single Responsibility Principle (SRP)

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

This means that a module or class should be responsible for performing a single function. If a class has multiple responsibilities, it becomes harder to maintain and test. Changes to one responsibility might inadvertently affect another.

Example: A class that handles user authentication should not also be responsible for sending email notifications. These are distinct responsibilities and should reside in separate classes.


// Bad example: Class with multiple responsibilities
class UserManager {
    public function createUser(User $user) { /* ... */ }
    public function deleteUser(User $user) { /* ... */ }
    public function sendWelcomeEmail(User $user) { /* ... */ }
    public function generateUserReport() { /* ... */ }
}

// Good example: Separate responsibilities
class UserRepository {
    public function createUser(User $user) { /* ... */ }
    public function deleteUser(User $user) { /* ... */ }
}

class EmailService {
    public function sendWelcomeEmail(User $user) { /* ... */ }
}

class UserReportGenerator {
    public function generateUserReport() { /* ... */ }
}

O - Open/Closed Principle (OCP)

Definition: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

This principle suggests that you should be able to add new functionality without altering existing code. This is often achieved through abstraction, interfaces, and inheritance. When requirements change, you extend the system rather than rewriting existing, working code.

Example: Instead of modifying a report generation class to add new report types, create new classes that extend a base report class or implement a report interface.


// Using an abstract class
abstract class Shape {
    abstract public function calculateArea(): float;
}

class Circle extends Shape {
    private $radius;
    public function __construct($radius) { $this->radius = $radius; }
    public function calculateArea(): float { return M_PI * $this->radius * $this->radius; }
}

class Square extends Shape {
    private $side;
    public function __construct($side) { $this->side = $side; }
    public function calculateArea(): float { return $this->side * $this->side; }
}

class AreaCalculator {
    public function calculateTotalArea(array $shapes): float {
        $totalArea = 0;
        foreach ($shapes as $shape) {
            $totalArea += $shape->calculateArea(); // Open for extension (new shapes)
        }
        return $totalArea;
    }
}

L - Liskov Substitution Principle (LSP)

Definition: Objects of a superclass should be replaceable with objects of its subclasses without altering the correctness of the program.

This principle ensures that if you have a base class and derive subclasses from it, you should be able to use instances of the subclasses in place of instances of the base class without causing errors or unexpected behavior.

Example: If you have a `Bird` class with a `fly()` method, a `Penguin` class (which is a type of bird) cannot implement `fly()`. This violates LSP. A better design would be to have `Bird` as a base, and `FlyingBird` and `NonFlyingBird` subclasses, or handle the ability to fly separately.


// Example violating LSP
class Bird {
    public function fly() { /* ... */ }
}
class Penguin extends Bird {
    public function fly() { throw new \Exception("Penguins can't fly!"); }
}

// Corrected approach (simplified)
interface CanFly {
    public function fly();
}
class Bird {
    // common bird properties
}
class Duck extends Bird implements CanFly {
    public function fly() { /* ... */ }
}
class Penguin extends Bird {
    // no fly method
}

I - Interface Segregation Principle (ISP)

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

Instead of having one large interface with many methods, it's better to have several smaller, specific interfaces. This ensures that a class implementing an interface only needs to provide implementations for the methods it actually uses, rather than being burdened with methods irrelevant to its functionality.

Example: A `Worker` interface with `work()` and `eat()` methods might be fine. But if you add `sleep()` and `program()`, it forces classes like `Robot` to implement methods they don't need or can't fulfill.


// Bad example: Fat interface
interface Worker {
    public function work();
    public function eat();
    public function sleep();
    public function program();
}

// Good example: Segregated interfaces
interface Workable {
    public function work();
}
interface Eatable {
    public function eat();
}
interface Sleepable {
    public function sleep();
}
interface Programmable {
    public function program();
}

class HumanWorker implements Workable, Eatable, Sleepable {
    public function work() { /* ... */ }
    public function eat() { /* ... */ }
    public function sleep() { /* ... */ }
}

class RobotWorker implements Workable, Programmable {
    public function work() { /* ... */ }
    public function program() { /* ... */ }
    // Doesn't implement Eatable or Sleepable
}

D - Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

This principle promotes loosely coupled architectures. Instead of a high-level module depending directly on a concrete low-level module, both should depend on an abstract interface or an abstract class. This makes it easier to swap out implementations of the low-level module without affecting the high-level module.

Example: A `ReportService` should not directly depend on a `MySqlDatabase` class. Instead, it should depend on a `DatabaseInterface`. Then, `MySqlDatabase` and `PostgresDatabase` can both implement `DatabaseInterface` and be injected into `ReportService`.


// Bad example: High-level module depends on low-level
class ReportService {
    private $database;

    public function __construct() {
        $this->database = new MySqlDatabase(); // Direct dependency
    }

    public function generateReport() {
        $data = $this->database->getData();
        // ...
    }
}

// Good example: Depend on abstraction
interface DatabaseInterface {
    public function getData();
}

class MySqlDatabase implements DatabaseInterface {
    public function getData() { /* ... */ }
}

class PostgresDatabase implements DatabaseInterface {
    public function getData() { /* ... */ }
}

class ReportService {
    private $database;

    // Dependency Injection via constructor
    public function __construct(DatabaseInterface $database) {
        $this->database = $database; // Depends on abstraction
    }

    public function generateReport() {
        $data = $this->database->getData();
        // ...
    }
}

Benefits of SOLID Principles