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