Why SOLID Principles Changed the Way I Write Code

Shivam Kumar — Sat, 24 Oct 2026 05:50:02 +0000

Every developer remembers the excitement of writing their first application. Seeing a program finally run after hours of debugging is incredibly satisfying.

But after building a few real projects, I noticed something interesting.

Writing code that works today is easy.

Writing code that still works six months later after dozens of new features is the real challenge.

As projects grow, small design mistakes become expensive. A simple feature request suddenly requires changes in multiple files. Fixing one bug unexpectedly breaks another module. Testing becomes frustrating because everything depends on everything else.

That's exactly why the SOLID Design Principles exist.

They aren't rules to make your code more complicated. They're guidelines that help you build software that's easier to maintain, extend, and scale.

Here's what I learned about each principle.

Why Good Code Eventually Becomes Bad Code

Most applications don't start out messy.

Imagine you're building an online shopping application.

At first, it only needs to:

Add products to a cart
Calculate totals
Generate invoices

The implementation is straightforward.

But after a few months, new requirements start arriving:

Support multiple payment gateways.
Store data in different databases.
Generate PDF invoices.
Send email receipts.
Add discount strategies.

If everything was built inside a few large classes, every new feature means modifying existing code.

Eventually, your project reaches a point where making one small change feels risky because you're never sure what else might break.

The problem isn't bad programming.

The problem is poor design.

SOLID provides a way to avoid that situation.

1. Single Responsibility Principle (SRP)

Every class should have one responsibility and one reason to change.

One lesson I've learned is that classes often become "do everything" classes without us realizing it.

Consider a ShoppingCart class.

At first, it calculates the total amount.

Later, it starts generating invoices.

Then it stores invoices in the database.

Soon it even sends confirmation emails.

Now one class is responsible for shopping, billing, storage, and communication.

If the invoice format changes, the shopping logic changes.

If the database changes, the shopping logic changes again.

That's a clear sign that the class has too many responsibilities.

A better design is to split responsibilities:

ShoppingCart → manages cart operations.
InvoicePrinter → formats and prints invoices.
InvoiceRepository → saves invoices.
EmailService → sends notifications.

Each component becomes smaller, easier to test, and easier to maintain.

2. Open/Closed Principle (OCP)

Software should be open for extension but closed for modification.

One of the biggest sources of bugs is modifying code that already works.

Imagine your application currently saves invoices in MySQL.

Months later, your company decides to migrate to MongoDB.

If you have to edit the existing storage class, you're risking bugs in functionality that was already stable.

Instead, create an abstraction.

InvoiceStorage
      ↑
 ├── MySQLStorage
 ├── MongoStorage
 └── PostgreSQLStorage

Now the application depends only on the common interface.

Adding a new database means creating another implementation rather than changing existing code.

This approach makes software much safer to evolve.

3. Liskov Substitution Principle (LSP)

Every subclass should behave like the class it replaces.

This principle is less about inheritance and more about trust.

Suppose you have a base class called Account.

Every account supports:

withdraw()

Now imagine introducing a FixedDepositAccount.

The problem?

Fixed deposit accounts don't allow withdrawals.

If someone writes:

Account account = new FixedDepositAccount();
account.withdraw();

the application either throws an exception or behaves unexpectedly.

Even though the code compiles, the design is broken.

A better solution is to model the real-world behavior correctly.

Account
      ↑
WithdrawableAccount
      ↑
 ├── SavingsAccount
 └── CurrentAccount

NonWithdrawableAccount
      ↑
FixedDepositAccount

Now every object behaves exactly as the caller expects.

Good inheritance should never surprise the developer using it.

4. Interface Segregation Principle (ISP)

Don't force classes to implement methods they don't need.

Large interfaces often create unnecessary work.

Imagine an interface like this:

Machine

with three methods:

print()
scan()
fax()

Now think about a basic home printer.

It only prints.

Why should it implement scanning and faxing?

Instead, split the interface into smaller ones:

Printable
Scannable
Faxable

Each device implements only the capabilities it actually supports.

Smaller interfaces make code cleaner and easier to understand.

5. Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations.

Business logic shouldn't care which database or external service is being used.

Without dependency inversion:

OrderService
      ↓
MySQLDatabase

The service becomes tightly coupled to MySQL.

Changing databases means modifying business logic.

A better architecture introduces an abstraction.

OrderService
      ↓
Database
      ↑
 ├── MySQLDatabase
 ├── MongoDatabase
 └── PostgreSQLDatabase

Now the service communicates with a common interface.

The implementation can change without affecting the business logic.

This design also makes unit testing much easier because mock implementations can replace real databases during testing.

Why These Principles Matter Together

Each SOLID principle solves a different design problem, but together they create software that is:

Easier to understand
Easier to test
Easier to extend
Easier to debug
Easier to maintain

Instead of building tightly connected classes, you build independent components that work together through well-defined contracts.

That's what makes large applications manageable.

Quick Cheat Sheet

Principle	Main Idea
S — Single Responsibility	One class should have one responsibility.
O — Open/Closed	Extend behavior without modifying existing code.
L — Liskov Substitution	Child classes should be usable wherever parent classes are expected.
I — Interface Segregation	Keep interfaces small and focused.
D — Dependency Inversion	Depend on abstractions rather than concrete implementations.

Final Thoughts

The biggest lesson I took away from learning SOLID is that software design isn't about predicting every future requirement—it's about making future changes easier.

No project stays the same forever. Requirements evolve, technologies change, and new features keep arriving. Code that isn't designed for change quickly becomes difficult to maintain.

SOLID won't magically make every project perfect, but it provides a practical foundation for writing software that can grow without becoming fragile.

If you're learning object-oriented programming or preparing for system design interviews, mastering these principles is one of the best investments you can make. They're not just interview topics—they're habits that improve the quality of every project you build.

DEV Community: Shivam Kumar