100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Python

Single Responsibility and Open/Closed Principles

Learn to split classes by responsibility and extend behavior with polymorphism instead of editing existing code.

SOLID PrinciplesIntermediate11 min readJul 8, 2026
Analogies

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

python
# --- 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

Was this page helpful?

Topics covered

#Python#SoftwareEngineeringStudyNotes#SoftwareEngineering#SingleResponsibilityAndOpenClosedPrinciples#Single#Responsibility#Open#Closed#StudyNotes#SkillVeris