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.