Devashish Roy

Posted on Nov 19

Understanding SOLID Principles — The Foundation of Better Software Design

#solidprinciples #softwareengineering #cleancode #programming

I am currently working on the project YouTubeLayer. The prototype worked fine initially, but when I tried to move it to a working production system and scale it, everything started breaking. It felt like playing Jenga — touch one block, and the whole tower comes crashing down.

That’s when I stumbled upon something that completely changed the way I thought about software design — the SOLID principles.

These five principles aren’t just fancy theory; they’re a way of writing code that’s easy to understand, extend, and maintain. And trust me — once you start applying them, your code (and your sanity) will thank you.

Let’s go through them one by one, in the simplest way possible 👇

🧩 S — Single Responsibility Principle (SRP)

Definition:
A class should have only one reason to change — in other words, it should do only one thing.

In plain English:
Don’t make a “God class” that does everything — logging, sending emails, calculating bills, and making coffee.

Example:
I once worked on a UserManager class that handled both user authentication and sending email notifications. Every time we updated the notification logic — like changing email templates or adding a new notification type — the authentication system mysteriously broke. 😅

We eventually split it into two separate classes — AuthManager for authentication and NotificationManager for sending emails. After that, changes became smooth and predictable. It was such a relief!

Why it matters:
It makes debugging, testing, and updating code simpler and safer.

🚪 O — Open/Closed Principle (OCP)

Definition:
Classes should be open for extension but closed for modification.

In plain English:
You should be able to add new features without touching existing code.

Example:
This reminds me of a time when I had to add subscription payments to my platform. Initially, all the payment logic lived inside one giant if-else block — handling credit cards, UPI, and wallets all in one place. When I tried adding a new option like PayPal, I had to dive back into that messy code and risk breaking existing functionality.

Later, I refactored the system by introducing a base Payment interface and creating separate classes like CreditCardPayment, UPIPayment, and PayPalPayment. After that, adding a new payment mode was as simple as creating a new class — no need to touch the old code. It felt like magic ✨

Why it matters:
It keeps old features safe while allowing new features to be added easily.

🔄 L — Liskov Substitution Principle (LSP)

Definition:
Subclasses should be replaceable with their parent classes without breaking the application.

In plain English:
If a subclass can’t perform the same role as its parent, it shouldn’t be a subclass.

Example:
This happened when I designed a Payment interface for my subscription system with a processSubscription() method. I had different payment classes like CreditCardPayment, UPIPayment, and CashOnDelivery.

At first, I thought they could all just extend Payment, but then I realized — Cash on Delivery couldn’t actually process a subscription renewal automatically. When I passed a CashOnDelivery object where a regular Payment object was expected, the system broke because it couldn’t handle renewals properly.

Lesson learned — not every subclass should substitute its parent. Inheritance (or implementation) should make logical sense for the behavior it represents.

Why it matters:
It ensures consistency and prevents unexpected behavior when using inheritance or interfaces.

🧱 I — Interface Segregation Principle (ISP)

Definition:
Clients shouldn’t be forced to depend on interfaces they don’t use.

In plain English:
Don’t create one huge interface — break it down into smaller, more specific ones.

Example:
This reminds me of a project where we had a Notifier interface with methods like sendEmail(), sendSMS(), and sendPushNotification().

But not every notification service supported all of these. For example, EmailNotifier didn’t need sendSMS() or sendPushNotification.

So I refactored it into smaller interfaces — EmailNotifier, SMSNotifier, and PushNotifier. That way, each service only implemented what it actually used.

Why it matters:
It keeps code modular and prevents classes from carrying unnecessary baggage.

⚙️ D — Dependency Inversion Principle (DIP)

Definition:
Depend on abstractions, not on concrete implementations.

In plain English:
High-level modules (like your business logic) shouldn’t depend on low-level modules (like database classes). Both should depend on an interface or abstraction.

Example:
When I built a logging feature, I initially called a FileLogger class directly. Later, when we switched to DatabaseLogger, I had to change everything. The fix? Use a Logger interface, and just swap implementations.

Why it matters:
It makes your code flexible and easy to maintain when changing technologies or components.

🧠 Wrapping It All Up

The SOLID principles are like a set of guardrails — they don’t restrict your creativity; they just keep you from falling off the cliff.

Here’s a quick recap:

Principle	Stands For	Key Idea
S	Single Responsibility	One class = one job
O	Open/Closed	Extend without modifying
L	Liskov Substitution	Subclasses should behave like their parents
I	Interface Segregation	No unnecessary interface methods
D	Dependency Inversion	Depend on abstractions, not concretes

When I look back, I realize the biggest jump in my programming maturity came when I stopped focusing on just writing code and started focusing on designing it well.

So next time you’re building something — pause for a moment and ask,

“Am I being SOLID about this?”

DEV Community