Introduction
The Single Responsibility Principle (SRP) and Open/Closed Principle (OCP) are the first two letters of SOLID, and they work hand in hand: SRP tells you how to split a class so it has one reason to change, and OCP tells you how to add new behavior to a system without touching code that already works.
Cricket analogy: SRP is like having a dedicated wicketkeeper and a separate strike bowler instead of one player doing both jobs poorly, and OCP is like adding a new bowling variation, such as a mystery spinner, to the attack without having to retrain the entire existing bowling unit.
Explanation
SRP defines 'responsibility' as a reason to change, often tied to a distinct actor or stakeholder. A class that both calculates an invoice total and formats it as HTML has two reasons to change: a change in tax rules, and a change in HTML markup. Splitting it into a calculator and a formatter means each class only changes for its own reason, which shrinks the blast radius of edits and makes each piece independently testable.
Cricket analogy: A player who is both the team's chief strategist and the wicketkeeper has two reasons to change their game: a shift in match tactics, and a shift in glovework technique; splitting these roles between a captain and a keeper means each only adjusts for their own reason.
OCP says a module should be extendable without modifying its existing, already-tested source. The classic way to violate OCP is an if/elif (or switch) chain that dispatches on a type code; every new case requires editing that chain. The classic way to satisfy OCP is polymorphism: define an abstract interface, implement new behavior as a new subclass or strategy object, and let the existing calling code work against the interface unchanged.
Cricket analogy: OCP is violated when a scorer's code has an if/elif chain checking 'if bowler is spinner, else if pacer, else if all-rounder' for every stat calculation, requiring an edit for each new player type; it's satisfied by defining a common Bowler interface so a new bowling style, like a leg-spinner, plugs in without touching existing scoring code.
Example
# --- BEFORE: violates SRP and OCP ---
class Invoice:
def __init__(self, items, discount_type):
self.items = items # list of (name, price)
self.discount_type = discount_type
def total(self):
subtotal = sum(price for _, price in self.items)
# OCP violation: adding a new discount type means editing this method
if self.discount_type == "none":
return subtotal
elif self.discount_type == "seasonal":
return subtotal * 0.9
elif self.discount_type == "loyalty":
return subtotal * 0.8
else:
raise ValueError("unknown discount type")
def to_html(self):
# SRP violation: this class also knows about presentation
rows = "".join(f"<tr><td>{n}</td><td>{p}</td></tr>" for n, p in self.items)
return f"<table>{rows}</table><p>Total: {self.total()}</p>"
# --- AFTER: SRP-compliant split + OCP-compliant extension point ---
from abc import ABC, abstractmethod
class DiscountPolicy(ABC):
@abstractmethod
def apply(self, subtotal: float) -> float:
...
class NoDiscount(DiscountPolicy):
def apply(self, subtotal: float) -> float:
return subtotal
class SeasonalDiscount(DiscountPolicy):
def apply(self, subtotal: float) -> float:
return subtotal * 0.9
class LoyaltyDiscount(DiscountPolicy):
def apply(self, subtotal: float) -> float:
return subtotal * 0.8
# New discount types are added by creating new classes -- no edits below.
class Invoice:
def __init__(self, items, discount_policy: DiscountPolicy):
self.items = items
self.discount_policy = discount_policy
def total(self) -> float:
subtotal = sum(price for _, price in self.items)
return self.discount_policy.apply(subtotal)
class InvoiceHtmlFormatter:
def render(self, invoice: Invoice) -> str:
rows = "".join(f"<tr><td>{n}</td><td>{p}</td></tr>" for n, p in invoice.items)
return f"<table>{rows}</table><p>Total: {invoice.total()}</p>"
Analysis
In the refactored version, Invoice has exactly one reason to change: how a total is computed from items and a discount policy. InvoiceHtmlFormatter has its own single reason to change: how invoices are rendered as HTML. Adding a new discount, such as a BulkOrderDiscount, requires only writing a new DiscountPolicy subclass; Invoice's source code is never touched again, satisfying OCP. This also makes unit testing easier, since each discount policy can be tested in isolation with simple inputs and outputs.
Cricket analogy: In the refactored setup, the wicketkeeper's only reason to change is glovework technique, and the strategist's only reason to change is tactical decisions; adding a new tactic, like an aggressive powerplay field, requires only a new strategy module, with the keeper's role never touched, making each independently trainable and testable.
Key Takeaways
- SRP: split classes so each one has a single, well-defined reason to change.
- A class mixing business logic with presentation or persistence usually violates SRP.
- OCP: prefer polymorphism (interfaces, strategy objects) over if/elif or switch chains that grow with every new case.
- New behavior should come from adding new classes, not editing tested ones.
- Together SRP and OCP make code easier to test, extend, and safely change.
Practice what you learned
1. A class that both validates user input and writes it to a database most likely violates:
2. Which technique typically helps satisfy the Open/Closed Principle when handling many type-specific behaviors?
3. In the refactored Invoice example, why can a new discount type be added without modifying the Invoice class?
4. What is the main benefit of separating Invoice and InvoiceHtmlFormatter into two classes?
Was this page helpful?
You May Also Like
SOLID Principles Overview
A guided tour of the five SOLID design principles that make object-oriented code easier to maintain and extend.
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.
Strategy and Command Patterns
Two behavioral patterns: Strategy swaps interchangeable algorithms at runtime; Command encapsulates a request as an executable object.
Code Quality and Refactoring
Learn how to measure code quality and use refactoring to improve internal structure without changing external behavior.
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