Once you start designing systems, a new challenge appears:
How do you ensure your design doesn’t break as it grows?
This is where most systems fail—not on day one, but after multiple changes.
Features get added, requirements evolve, and suddenly:
- one change breaks multiple things
- code becomes harder to understand
- adding new behavior feels risky
SOLID principles exist to prevent exactly this.
In this post, we’ll cover the first two:
- SRP (Single Responsibility Principle)
- OCP (Open Closed Principle)
The real problem
Let’s take a simple example:
OrderService:
- create_order()
- process_payment()
- send_email()
At first, this feels convenient.
Everything is in one place.
But over time:
- payment logic changes
- email format changes
- order flow changes
Now this one class needs constant modification.
That’s where problems begin.
SRP — Single Responsibility Principle
A class should have only one reason to change.
In simple terms:
A class should do one thing, and do it well.
What goes wrong without SRP
In the previous example, OrderService is handling:
- order creation
- payment
- notifications
These are different responsibilities.
So:
- payment changes → OrderService changes
- email changes → OrderService changes
One class, multiple reasons to change → fragile design.
Applying SRP
Break responsibilities:
OrderService → create_order()
PaymentService → process_payment()
NotificationService → send_email()
Now:
- each class has a clear purpose
- changes are isolated
- system becomes easier to maintain
OCP — Open Closed Principle
Software should be open for extension, but closed for modification.
This means:
- You should be able to add new behavior
- Without changing existing code
The common mistake
Let’s say you support payments:
if type == "CARD":
process_card()
elif type == "UPI":
process_upi()
Now you want to add:
- Wallet
- Net banking
You keep modifying the same code.
This violates OCP.
Applying OCP
Instead, design for extension:
Payment:
- pay()
CardPayment → pay()
UPIPayment → pay()
WalletPayment → pay()
Now:
- adding a new payment method = new class
- existing code remains untouched
Why SRP + OCP matter together
- SRP ensures classes are focused
- OCP ensures systems are extensible
Together, they help you build systems that:
- don’t break easily
- grow without chaos
A subtle shift in thinking
Instead of writing code like:
“What do I need right now?”
Start thinking:
“What might change in the future, and how can I isolate it?”
Closing thought
Most systems don’t fail because they can’t handle today’s requirements.
They fail because they weren’t designed to handle change.
Top comments (0)