Devnary

When I started coding, my main goal was simple:
“If it runs without errors, it’s done.”

But as I worked on more projects, I realized something important.
Code that works is not always good code.

That’s when I came across SOLID principles, and they completely changed how I think about writing software.

---

What Does SOLID Mean?

As a learner, SOLID helped me move from just making things work to making things work well.

---

S – Single Responsibility Principle

A class should have one, and only one, reason to change

Earlier, I used to put many responsibilities into one class.
Now, I try to separate concerns so each class has one clear purpose.

Bad (Without SRP)

class UserService {
    void saveUser() {}
    void sendEmail() {}
}

Good (With SRP)

class UserService {
    void saveUser() {}
}

class EmailService {
    void sendEmail() {}
}

Benefits: Easier to read, Easier to maintain, Reduces risk of bugs when changes are needed

---

O – Open/Closed Principle

Software entities should be open for extension, but closed for modification

Instead of modifying old code again and again, I learned to extend behavior using interfaces or inheritance.

interface Payment {
    void pay();
}

Use interfaces or abstract classes: In there, I can add new payment methods without modifying old code.

Why it matters: Minimizes risk of breaking existing functionality, Makes code more modular and reusable

---

L – Liskov Substitution Principle

Subtypes must be substitutable for their base types without altering desirable behavior

If a class inherits from another, it should behave predictably in place of its parent.

Key takeaway: Proper inheritance ensures safe polymorphism and avoids runtime surprises.

---

I – Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use

Using small and focused interfaces made my classes simpler and easier to manage.

Bad (Without ISP)

interface Machine {
    void print();
    void scan();
    void fax();
}

Good (With ISP)

interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

Benefit: Makes code simpler, more flexible, and easier to maintain.

---

D – Dependency Inversion Principle

At first, this sounded complicated, but now I see it as

Depend on abstractions, not concrete implementations.

High-level modules should not depend directly on low-level modules. Both should rely on interfaces or abstract classes.

Why it matters: Promotes loose coupling, Makes code easier to test, Simplifies swapping or updating implementations

---

Applying SOLID principles changed the way I think about coding,

• From just making it run to designing robust and maintainable solutions
• From tightly coupled systems to flexible and modular architecture
• From temporary fixes to long-term solutions

Even as I continue learning, SOLID provides a solid foundation for writing professional-quality software.

But here’s an important point.
SOLID is not a set of rigid rules. It’s a set of best-practice guidelines. It helps you think critically about design, make better decisions, and avoid common pitfalls, but it’s okay to adapt them depending on your project, context, and goals.

Moving from “It works” to “It’s SOLID” is more than a coding technique. It’s a mindset shift.

Start small. Apply the principles gradually. With practice, your code will not only work. It will last, scale, and stay clean.