🏛️ 5 Pillars of SOLID

When it comes to writing clean and maintainable code, the SOLID principles are essential tools every developer should know. But here’s the truth: it's not just about memorizing five fancy terms — it's about recognizing when and how to apply them in real code. You don’t need to recite the definitions — you need to practice them.
The more you apply these principles, the more they become second nature, improving your design decisions over time. Keep this guide handy, and focus on using SOLID whenever you see the opportunity.

Letter	Principle Name	Abbreviation	Key Idea
S	Single Responsibility Principle	SRP	One class = One responsibility
O	Open/Closed Principle	OCP	Open to extension, closed to modification
L	Liskov Substitution Principle	LSP	Subtypes must be substitutable for base types
I	Interface Segregation Principle	ISP	No forcing of unused methods; favor small, focused interfaces
D	Dependency Inversion Principle	DIP	Depend on abstractions, not concrete implementations

🧱 S — Single Responsibility Principle (SRP)

✅ A class should have only one reason to change. Each class should handle a single part of the functionality.

🔥 Bad Example:

class UserManager:
    def add_user(self, user):
        # Add user to database
        pass

    def send_email(self, user, message):
        # Send welcome email
        pass

✅ Good Example:

class UserManager:
    def add_user(self, user):
        # Add user to database
        pass

class EmailService:
    def send_email(self, user, message):
        # Send email
        pass

🎯 When & Why:

Use SRP to make your code easier to understand, test, and modify. Changes in one responsibility won't break others.

🧱 O — Open/Closed Principle (OCP)

✅ Software should be open for extension but closed for modification.

🔥 Bad Example:

class Discount:
    def get_discount(self, customer_type):
        if customer_type == "regular":
            return 0.1
        elif customer_type == "vip":
            return 0.2

✅ Good Example:

class Discount:
    def get_discount(self):
        return 0.0

class RegularDiscount(Discount):
    def get_discount(self):
        return 0.1

class VIPDiscount(Discount):
    def get_discount(self):
        return 0.2

🎯 When & Why:

Use it when you expect requirements to evolve. This allows you to add new behavior with new classes without touching existing tested code.

🧱 L — Liskov Substitution Principle (LSP)

✅ Subclasses should be replaceable for their parent classes without altering program behavior.

🔥 Bad Example:

class Bird:
    def fly(self):
        print("Flying")

class Penguin(Bird):
    def fly(self):
        raise Exception("Penguins can't fly")

✅ Good Example:

class Bird:
    pass

class FlyingBird(Bird):
    def fly(self):
        print("Flying")

class Penguin(Bird):
    def swim(self):
        print("Swimming")

🎯 When & Why:

The Liskov Substitution Principle (LSP) applies when using inheritance. It ensures that a subclass can stand in for its parent class without breaking the program.

🧱 I — Interface Segregation Principle (ISP)

✅ Clients should not be forced to depend on methods they do not use.

🔥 Bad Example:

class Machine:
    def print(self): pass
    def scan(self): pass
    def fax(self): pass

class OldPrinter(Machine):
    def print(self): pass
    def scan(self): raise NotImplementedError()
    def fax(self): raise NotImplementedError()

✅ Good Example:

class Printer:
    def print(self): pass

class Scanner:
    def scan(self): pass

class Fax:
    def fax(self): pass

class OldPrinter(Printer):
    def print(self): pass

🎯 When & Why:

Use ISP to keep interfaces lean and focused. This avoids forcing classes to implement irrelevant functionality.

D — Dependency Inversion Principle (DIP)

✅ High-level modules should depend on abstractions, not on low-level modules.

🔥 Bad Example:

class MySQLDatabase:
    def connect(self):
        pass

class DataService:
    def __init__(self):
        self.db = MySQLDatabase()

✅ Good Example:

class Database:
    def connect(self):
        pass

class MySQLDatabase(Database):
    def connect(self):
        pass

class DataService:
    def __init__(self, db: Database):
        self.db = db

🎯 When & Why:

Use DIP to make your code more testable and flexible. It allows you to swap out implementations (e.g., use a mock DB during tests).

✅ Conclusion

The SOLID principles are timeless guidelines for writing clean, modular, and maintainable object-oriented code. By following:

• SRP — keep responsibilities focused,

• OCP — allow easy feature expansion,

• LSP — ensure consistent behavior in subclasses,

• ISP — build focused and usable interfaces,

• DIP — depend on abstractions for flexibility,

you create software that is easier to test, scale, and adapt to change. Applying SOLID isn't about rigid rules — it's about writing thoughtful, future-proof code.