SOLID Principles

Five core principles of object-oriented design that lead to systems which are simpler to maintain, test, and extend. Robert C. Martin (Uncle Bob) formalized these ideas, and Michael Feathers coined the SOLID acronym.

Principle Index

Principle Summary Reference

S — Single Responsibility A class should have only one reason to change reference

O — Open/Closed Open for extension, closed for modification reference

L — Liskov Substitution Subtypes must be substitutable for their base types reference

I — Interface Segregation Prefer many specific interfaces over one general-purpose interface reference

D — Dependency Inversion Depend on abstractions, not concretions reference

Why SOLID Matters

Without SOLID, codebases gradually develop these problems:

• Rigidity — one change ripples through many unrelated modules

• Fragility — modifying one area breaks another seemingly unconnected area

• Immobility — components are so intertwined that extracting them for reuse is impractical

• Viscosity — doing things correctly is harder than hacking around the design

SOLID tackles each of these by defining clear boundaries, explicit contracts, and flexible points for extension.

Quick Decision Guide

Symptom Likely Violated Principle Fix

Class does too many things SRP Split into focused classes

Adding a feature requires editing existing classes OCP Introduce polymorphism or strategy

Subclass breaks when used in place of parent LSP Fix inheritance hierarchy or use composition

Classes forced to implement unused methods ISP Break interface into smaller ones

High-level module imports low-level details DIP Introduce an abstraction layer

Quick Examples

SRP — Before and After

// BEFORE: Class handles both user data AND email sending class UserService { public function createUser(string $name, string $email): void { /* ... / } public function sendWelcomeEmail(string $email): void { / ... */ } }

// AFTER: Each class has one responsibility class UserService { public function __construct(private UserNotifier $notifier) {} public function createUser(string $name, string $email): void { // persist user... $this->notifier->welcomeNewUser($email); } }

class UserNotifier { public function welcomeNewUser(string $email): void { /* ... */ } }

OCP — Extend Without Modifying

interface DiscountPolicy { public function calculate(float $total): float; }

class PercentageDiscount implements DiscountPolicy { public function __construct(private float $rate) {} public function calculate(float $total): float { return $total * $this->rate; } }

// Adding a new discount type requires NO changes to existing code class FlatDiscount implements DiscountPolicy { public function __construct(private float $amount) {} public function calculate(float $total): float { return min($this->amount, $total); } }

DIP — Depend on Abstractions

// High-level policy depends on abstraction, not on database details interface OrderRepository { public function save(Order $order): void; }

class PlaceOrderHandler { public function __construct(private OrderRepository $repository) {} public function handle(PlaceOrderCommand $cmd): void { $order = Order::create($cmd->items); $this->repository->save($order); } }

Relationships Between Principles

The five principles complement and reinforce one another:

• SRP + ISP: Both narrow the surface area of a class or interface to a single, focused concern

• OCP + DIP: Abstractions are the mechanism that enables extension without modification

• LSP + OCP: Correct substitutability is essential for polymorphic extension to work

• ISP + DIP: Well-segregated interfaces make it easier to depend on precisely the right abstraction

Common Misconceptions

• "One method per class" — SRP means one reason to change, not one method. A class can contain many methods as long as they all serve the same responsibility.

• "Never modify existing code" — OCP does not prohibit bug fixes. It means new behavior should be introducible without changing existing working code.

• "Always use interfaces" — DIP calls for depending on abstractions. Sometimes a well-crafted base class is the appropriate abstraction. Do not create interfaces for classes that will never have a second implementation.

• "Inheritance is bad" — LSP does not discourage inheritance. It establishes rules for correct inheritance so that subtypes remain safely substitutable.

Best Practices

• Adopt SOLID incrementally — do not refactor everything in one pass

• Treat SOLID as a diagnostic tool: when code resists change, check which principle is being violated

• Pair with design patterns — Strategy (OCP), Adapter (DIP), and Decorator (OCP) are direct implementations of SOLID ideas

• Write tests first — TDD naturally steers designs toward SOLID compliance

• Target PHP 8.3+ with strict typing, readonly classes, and enums