Introduction
SOLID is an acronym coined by Robert C. Martin (Uncle Bob) that groups five object-oriented design principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. Together they guide developers toward code that is easier to understand, test, and change without introducing regressions.
Cricket analogy: SOLID is like a set of five coaching principles a head coach establishes for the whole academy, covering everything from how specialist roles are defined to how new drills get added, so every young player develops technique that holds up under match pressure.
Explanation
Single Responsibility Principle (SRP) states that a class should have only one reason to change, meaning it should encapsulate a single piece of functionality or business capability. Open/Closed Principle (OCP) states that software entities should be open for extension but closed for modification, so new behavior is added through new code rather than by editing existing, tested code. Liskov Substitution Principle (LSP) states that objects of a subclass must be substitutable for objects of their superclass without breaking the correctness of the program. Interface Segregation Principle (ISP) states that clients should not be forced to depend on methods they do not use, favoring several small, focused interfaces over one large, general-purpose interface. Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules; both should depend on abstractions, and abstractions should not depend on details.
Cricket analogy: SRP: a wicketkeeper only keeps wicket, not also opens the bowling. OCP: adding a new fielding formation without rewriting the existing batting order. LSP: any substitute fielder brought on must field the position without surprising the captain. ISP: a spin specialist isn't forced to train fast-bowling drills. DIP: the team's game plan depends on an abstract 'death bowler' role, not one specific named player.
Example
# A tiny illustration touching all five letters conceptually
from abc import ABC, abstractmethod
# SRP: this class only formats receipts, nothing else
class ReceiptFormatter:
def format(self, order):
return f"Total: ${order.total:.2f}"
# OCP + LSP + ISP: a small abstraction that new discount types can extend
class DiscountStrategy(ABC):
@abstractmethod
def apply(self, total: float) -> float:
...
class NoDiscount(DiscountStrategy):
def apply(self, total: float) -> float:
return total
class TenPercentOff(DiscountStrategy):
def apply(self, total: float) -> float:
return total * 0.9
# DIP: OrderProcessor depends on the DiscountStrategy abstraction,
# not on a concrete discount implementation
class OrderProcessor:
def __init__(self, discount: DiscountStrategy):
self.discount = discount
def checkout(self, total: float) -> float:
return self.discount.apply(total)
Analysis
None of these principles are laws to apply blindly everywhere; they are heuristics that trade a small amount of upfront structure for large gains in maintainability as a codebase grows. Overapplying SOLID to a tiny script adds needless indirection, but ignoring it in a large, evolving system leads to tangled classes, fragile inheritance hierarchies, and code that is painful to test. The next three topics in this module dive deeper into each pair of principles with dedicated before/after examples.
Cricket analogy: None of these coaching principles are laws for every net session; overcoaching a village-level friendly with elaborate role separation is overkill, but ignoring structure in a national academy leads to tangled roles and players who can't cover for each other under pressure.
Key Takeaways
- SRP: a class should have exactly one reason to change.
- OCP: extend behavior through new code, not by editing existing code.
- LSP: subclasses must honor the contract of their base class so they can be substituted safely.
- ISP: prefer several small, client-specific interfaces over one large interface.
- DIP: depend on abstractions, not on concrete implementations.
Practice what you learned
1. What does the 'S' in SOLID stand for?
2. Which principle states that software entities should be open for extension but closed for modification?
3. The Dependency Inversion Principle primarily recommends that:
4. Which principle is most directly violated by a single 'God interface' with 20 unrelated methods that every client must implement?
Was this page helpful?
You May Also Like
Single Responsibility and Open/Closed Principles
Learn to split classes by responsibility and extend behavior with polymorphism instead of editing existing code.
Liskov Substitution and Interface Segregation
Understand why subtypes must honor their base type's contract and why fat interfaces should be split into focused ones.
Dependency Inversion
Distinguish the Dependency Inversion Principle from Dependency Injection and apply constructor injection against an abstraction.
Design Patterns Overview
An introduction to the Gang of Four design patterns and their three categories: Creational, Structural, and Behavioral.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics
Software EngineeringSystem Design Study Notes
Architecture · 40 topics