Software → Software Design
SRP
A module, class, or function should have one primary reason to change.
Motivation
SRP solves the problem of one class changing for unrelated reasons. When validation, pricing, persistence, and notification logic all live together, every business change risks breaking unrelated behavior.
Where it fits
SRP belongs to SOLID and software design. It is closely related to cohesion, modularity, and maintainable boundaries.
class OrderService: def checkout(self, order): if not order.items: raise ValueError("empty order") total = sum(item.price for item in order.items) print(f"Charging {total}") print("Saving order") print("Sending confirmation email")class OrderValidator: def validate(self, order): if not order.items: raise ValueError("empty order")class OrderPricer: def total(self, order): return sum(item.price for item in order.items)class OrderService: def __init__(self, validator, pricer, payment, repository, notifier): self.validator = validator self.pricer = pricer self.payment = payment self.repository = repository self.notifier = notifier def checkout(self, order): self.validator.validate(order) total = self.pricer.total(order) self.payment.charge(total) self.repository.save(order) self.notifier.confirm(order)Common mistakes
- Splitting every method into a new class without improving cohesion.
- Defining “responsibility” too narrowly. SRP is about reasons to change, not line count.