SOLID Principles Deep Dive (S, O, L): Explained from Absolute Zero 🧱

🧱 SOLID Principles Deep Dive (S, O, L): Let's Learn from ZERO!

SOLID shows up in Python, FastAPI, Java, Spring Boot, React architecture and almost every real-world codebase. Interviewers and mentors rarely stop at "define SOLID". They ask why we use it, what problem it solves, and how you apply it in a project. 🎯

In this post we'll cover the first three principles, S, O and L, step by step, with simple examples and practical code. 🚀

---

1. 🤔 First, What Are SOLID Principles?

Imagine you're building an Instagram-like social media app with registration and login, posts, image uploads, likes, comments, notifications and follows. At first you write everything in one huge class:

class SocialMedia:
    def register_user(self):
        pass

    def login_user(self):
        pass

    def create_post(self):
        pass

    def upload_image(self):
        pass

    def like_post(self):
        pass

    def comment_on_post(self):
        pass

    def send_notification(self):
        pass

It works, right? But when the app grows to 100 features:

• 😵 Changing login might accidentally affect registration
• 😵 Changing image upload might affect post creation
• 🧪 Testing individual features becomes difficult
• ♻️ Reusing functionality becomes difficult
• 🐌 Adding new features gets complicated

This is tightly coupled, poorly organized code. We need a better way to design software. That's where SOLID comes in!

🔤 What does SOLID stand for?

Letter	Principle	One-line idea
S	Single Responsibility	One class should have one responsibility
O	Open/Closed	Open for extension, closed for modification
L	Liskov Substitution	Child classes should safely replace parent classes
I	Interface Segregation	Don't force classes to implement methods they don't need
D	Dependency Inversion	Depend on abstractions, not concrete implementations

Today we'll go deep on S, O and L.

---

2. 1️⃣ S: Single Responsibility Principle (SRP)

2.1 🤔 What does it mean?

📌 A class should have only one reason to change.

• Single = one
• Responsibility = one specific job
• Principle = a rule to follow

In simple English: a class should focus on one particular job instead of handling several unrelated ones.

🍽️ Real-life example: a restaurant chef prepares food. The chef should not also manage customer payments, clean the whole restaurant, maintain the database or handle salaries. Those jobs belong to other people or departments. When one responsibility changes, it shouldn't unnecessarily affect everything else. The same logic applies to classes.

2.2 ❌ SRP with bad code

A user can register, be saved to a database, and receive a welcome email. A beginner might write:

class User:
    def register(self, username, email):
        # Validate user
        print("User registered")

        # Save user to database
        print("Saving user to database")

        # Send welcome email
        print("Sending welcome email")

This class has three different responsibilities:

Functionality	Responsibility
Validate user	Business validation
Save user	Database operations
Send email	Email communication

Now imagine:

• 📧 The email provider changes from Gmail SMTP to SendGrid → modify User
• 🗄️ The database changes from PostgreSQL to MySQL → modify User
• ✅ Validation rules change → modify User

The class has multiple reasons to change. That's an SRP violation. 🚨

2.3 ✅ Correct implementation using SRP

Separate responsibilities into different classes:

UserService     → handles user registration business logic
UserRepository  → database operations
EmailService    → email operations

Class 1: UserRepository (only database operations)

class UserRepository:
    def save_user(self, username, email):
        print("Saving user to database")

Class 2: EmailService (only sending emails)

class EmailService:
    def send_welcome_email(self, email):
        print("Sending welcome email")

Class 3: UserService (coordinates the registration process)

class UserService:
    def __init__(self, repository, email_service):
        self.repository = repository
        self.email_service = email_service

    def register_user(self, username, email):
        print("Validating user")

        self.repository.save_user(username, email)
        self.email_service.send_welcome_email(email)

        print("Registration completed")

Run it:

repository = UserRepository()
email_service = EmailService()

user_service = UserService(
    repository,
    email_service,
)

user_service.register_user(
    "Deepika",
    "[e-mail]",
)

Validating user
Saving user to database
Sending welcome email
Registration completed

Each class now has a clear responsibility.

📝 UserService still coordinates several steps, but its responsibility is the registration use case. Having multiple method calls doesn't automatically violate SRP.

2.4 ✅ Why is SRP important?

Benefit	Explanation
🛠️ Maintainability	Easier to modify individual functionality
♻️ Reusability	Reuse EmailService in other modules
🧪 Testability	Test each class independently
📖 Readability	Code becomes easier to understand
🛡️ Reduced side effects	Changes are less likely to break unrelated features

2.5 ⚡ SRP in a FastAPI backend

backend/
└── app/
    ├── api/
    │   └── routes/
    │       ├── auth.py
    │       └── posts.py
    │
    ├── services/
    │   ├── auth_service.py
    │   └── post_service.py
    │
    ├── repositories/
    │   ├── user_repository.py
    │   └── post_repository.py
    │
    └── models/
        ├── user.py
        └── post.py

Layer	Responsibility
🛣️ API routes	Receive HTTP requests and return responses
🧠 Services	Handle business logic
📚 Repositories	Communicate with the database
🗄️ Models	Represent database entities

For example: auth.py handles login and registration endpoints, auth_service.py handles authentication business logic, user_repository.py handles user database operations, and user.py represents the User database model. This separation supports SRP.

🎤 Interview question: What happens if we put database queries, business logic and HTTP request handling inside one route function?

Answer: The route becomes responsible for too many things. It becomes harder to test, maintain, reuse and modify independently.

---

3. 2️⃣ O: Open/Closed Principle (OCP)

3.1 🤔 What does it mean?

📌 Software entities should be open for extension but closed for modification.

It sounds confusing at first, so let's take each phrase:

• Open for extension → we can add new functionality
• Closed for modification → we avoid repeatedly changing existing, working code to support every new requirement

⚠️ It does NOT mean existing code can never be changed. It means designing code so that adding a feature usually doesn't require modifying existing, stable logic.

💳 Real-life example: a payment app first supports credit and debit cards. Later the company adds UPI, PayPal and net banking. A poorly designed system forces you to change the same payment-processing function every time. A better design lets you add new payment methods without rewriting the existing payment flow.

3.2 ❌ OCP with bad code

class PaymentService:
    def pay(self, payment_type, amount):
        if payment_type == "card":
            print("Processing card payment")
        elif payment_type == "upi":
            print("Processing UPI payment")
        elif payment_type == "paypal":
            print("Processing PayPal payment")

It works! But tomorrow we add Google Pay, so we modify pay(). Next month another method, and we modify pay() again. The method keeps growing with new conditions, which makes it harder to maintain and increases the chance of breaking existing functionality.

3.3 ✅ Correct implementation using OCP

We use abstraction and polymorphism. Don't worry, we'll explain both.

First, a common interface using Python's ABC. An interface is essentially a contract that says which methods an implementation must provide.

from abc import ABC, abstractmethod


class PaymentMethod(ABC):
    @abstractmethod
    def pay(self, amount):
        pass

• ABC lets us define an abstract base class
• @abstractmethod declares a method that child classes must implement
• PaymentMethod defines the common contract

Now the different payment methods:

class CardPayment(PaymentMethod):
    def pay(self, amount):
        print(f"Paid {amount} using Card")


class UPIPayment(PaymentMethod):
    def pay(self, amount):
        print(f"Paid {amount} using UPI")


class PayPalPayment(PaymentMethod):
    def pay(self, amount):
        print(f"Paid {amount} using PayPal")

The payment service:

class PaymentService:
    def process_payment(self, payment_method, amount):
        payment_method.pay(amount)

Run it:

service = PaymentService()

card = CardPayment()
upi = UPIPayment()
paypal = PayPalPayment()

service.process_payment(card, 1000)
service.process_payment(upi, 500)
service.process_payment(paypal, 2000)

Paid 1000 using Card
Paid 500 using UPI
Paid 2000 using PayPal

Now the business introduces Google Pay. We simply add another class:

class GooglePay(PaymentMethod):
    def pay(self, amount):
        print(f"Paid {amount} using Google Pay")

google_pay = GooglePay()
service.process_payment(google_pay, 1500)

Paid 1500 using Google Pay

Look carefully: we did not modify the existing PaymentService class. We extended the system by adding a new implementation. OCP achieved! 🎉

3.4 🎭 What is polymorphism here?

📌 Polymorphism means one common interface, many different implementations.

payment_method.pay(amount)

The same method call behaves differently depending on the object passed:

Object	What happens?
CardPayment	Card payment
UPIPayment	UPI payment
PayPalPayment	PayPal payment
GooglePay	Google Pay payment

Same method name, different behavior. That's polymorphism.

3.5 ✅ Why is OCP important?

• ➕ Adding new features becomes easier
• 🧱 Existing tested code stays stable
• 🔁 Reduces repeated modifications
• 📈 Improves scalability
• 🛡️ Reduces the risk of introducing bugs into existing functionality

3.6 📱 OCP in a social media app

Your app supports email notifications at first. Later you add push, SMS and in-app notifications. Instead of one huge function with many if/elif branches, create a common notification interface. Each notification type implements its own sending behavior. When a new type arrives, you add a new implementation and don't rewrite the main notification-processing logic.

🎤 Interview question: Why is OCP useful in a growing application?

Answer: Requirements change frequently. OCP lets developers add new functionality through extension instead of repeatedly modifying existing, stable code, reducing the risk of breaking existing features.

---

4. 3️⃣ L: Liskov Substitution Principle (LSP)

Probably the trickiest of the three at first. But once you see the example, it's easy. 😄

4.1 🤔 What does it mean?

📌 Objects of a parent class should be replaceable with objects of its child classes without breaking the correctness of the program.

• Parent class = base class
• Child class = derived class
• Substitution = replacing one thing with another

In simple English: if a child class inherits from a parent class, the child should behave in a way that is compatible with what the parent promises. Wherever you use a child object instead of a parent object, the application should keep working correctly.

🧬 First, understand inheritance

Inheritance is when one class acquires properties and methods from another:

class Animal:
    def eat(self):
        print("Animal is eating")


class Dog(Animal):
    def bark(self):
        print("Dog is barking")

Animal is the parent, Dog is the child, and Dog inherits eat():

dog = Dog()
dog.eat()
dog.bark()

Animal is eating
Dog is barking

But LSP asks something more important: can we safely use the child class wherever the parent class is expected?

4.2 🐦 Real-life example: birds

class Bird:
    def fly(self):
        print("Bird is flying")


class Sparrow(Bird):
    def fly(self):
        print("Sparrow is flying")


class Eagle(Bird):
    def fly(self):
        print("Eagle is flying")

Both can fly, so everything is fine. Now:

def make_bird_fly(bird):
    bird.fly()


make_bird_fly(Sparrow())
make_bird_fly(Eagle())

Sparrow is flying
Eagle is flying

The child objects substitute for the parent type without problems. That's LSP. ✅

4.3 ❌ Understanding an LSP violation

Now we introduce a Penguin. Can a penguin fly? No! But our parent class says every Bird has a fly() method.

class Penguin(Bird):
    def fly(self):
        raise Exception("Penguins cannot fly")


penguin = Penguin()
make_bird_fly(penguin)

Exception: Penguins cannot fly

make_bird_fly() expects a bird that can fly. Penguin inherits from Bird but breaks that expectation. The parent promises flying behavior, and the child can't deliver it. This is a classic Liskov Substitution Principle violation. 🚨

4.4 ✅ How do we fix it?

Redesign the hierarchy. Instead of saying every Bird can fly, separate general bird behavior from flying behavior:

class Bird:
    def eat(self):
        print("Bird is eating")


class FlyingBird(Bird):
    def fly(self):
        print("Bird is flying")


class Sparrow(FlyingBird):
    def fly(self):
        print("Sparrow is flying")


class Eagle(FlyingBird):
    def fly(self):
        print("Eagle is flying")


class Penguin(Bird):
    def swim(self):
        print("Penguin is swimming")

Bird           → common bird behavior: eat()
 ├── FlyingBird → fly()
 │     ├── Sparrow
 │     └── Eagle
 └── Penguin    → swim()   (does not promise flying behavior)

Now:

def make_bird_fly(bird: FlyingBird):
    bird.fly()


make_bird_fly(Sparrow())
make_bird_fly(Eagle())

We don't pass Penguin. The design now reflects the actual capabilities of the objects.

💡 LSP isn't simply about whether inheritance exists. It's about whether the child class honors the behavioral contract of the parent class.

4.5 📐 Another important example: Rectangle and Square

A famous interview example. Mathematically a square is a special kind of rectangle, so a developer might try this:

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def set_width(self, width):
        self.width = width

    def set_height(self, height):
        self.height = height

    def area(self):
        return self.width * self.height


class Square(Rectangle):
    def set_width(self, width):
        self.width = width
        self.height = width

    def set_height(self, height):
        self.width = height
        self.height = height

Test it:

def calculate_area(rectangle):
    rectangle.set_width(5)
    rectangle.set_height(10)
    return rectangle.area()

With a normal rectangle:

rectangle = Rectangle(2, 3)
print(calculate_area(rectangle))   # 50 ✅

With a square:

square = Square(2, 2)
print(calculate_area(square))      # 100 ❌

Why? Setting the height to 10 also changes the square's width to 10. The function expected a rectangle whose width and height can change independently, and Square breaks that expectation. That's an LSP violation.

🧠 The lesson: a mathematically valid inheritance relationship doesn't always make a good software inheritance relationship.

4.6 🔍 How to spot LSP violations

Warning signs:

1. A child method throws an exception for behavior the parent promises to support
2. A child method does nothing when the parent promises meaningful behavior
3. A child changes the expected output or behavior in an incompatible way
4. A child requires stricter inputs than the parent
5. A child returns weaker or incompatible results than the parent contract promises

There are deeper formal rules behind this:

• Preconditions should not be strengthened
• Postconditions should not be weakened
• Parent invariants should be preserved

Term	Simple meaning
Preconditions	What must be true before a method runs
Postconditions	What the method guarantees after execution
Invariants	Rules that must stay true throughout the object's valid lifetime

For example, if a parent method accepts any positive number, a child shouldn't suddenly accept only numbers greater than 100. That would strengthen the precondition and violate LSP.

4.7 ✅ Why is LSP important?

• 🔒 Makes inheritance reliable
• 🚫 Prevents unexpected runtime errors
• ♻️ Improves code reusability
• 🎭 Makes polymorphism safer
• 🏗️ Helps you design correct class hierarchies
• 🧪 Makes unit testing easier, because child objects can be tested against parent expectations

---

5. ⚖️ Comparing S, O and L

Principle	Main question	Problem it prevents
S: SRP	Does this class have one clear responsibility?	Classes doing too many unrelated jobs
O: OCP	Can I add features without repeatedly modifying stable code?	Constant modification of existing logic
L: LSP	Can a child object replace its parent safely?	Incorrect inheritance and unexpected behavior

One example to remember each:

• 🅢 SRP: a User class shouldn't handle everything. Separate database operations, email sending and registration.
• 🅞 OCP: adding Google Pay shouldn't require rewriting PaymentService. Add a new implementation of the common contract.
• 🅛 LSP: a Penguin shouldn't be forced to implement flying. Design inheritance around actual behavioral capabilities.

---

6. 🤝 How Are These Principles Related?

They're separate, but they complement each other. Imagine an e-commerce backend with PaymentService, EmailService, OrderService, PaymentMethod, CardPayment and UPIPayment:

• SRP: each class has a well-defined responsibility
• OCP: you can introduce a new payment method without changing the existing payment-processing logic
• LSP: every payment implementation honors the common PaymentMethod contract, so the payment service can safely use any of them

One good design can follow all three principles at once. ✨

---

7. ⚠️ Common Mistakes with SOLID

Following SOLID doesn't mean creating hundreds of unnecessary classes.

Mistake	Correct understanding
"SRP means one method per class"	No. It means one cohesive responsibility per class
"OCP means never modify existing code"	No. It means designing for extension without unnecessary modification
"LSP means every child must have exactly the same code as its parent"	No. Children can implement things differently but must preserve expected behavior
"More classes always mean better SOLID design"	No. Avoid unnecessary complexity
"Inheritance automatically means LSP is satisfied"	No. Behavioral compatibility is what matters

---

8. 🎤 Interview Questions and Answers

Q1. What is SOLID?
A collection of five object-oriented design principles that help developers write maintainable, flexible, reusable and scalable software.

Q2. What's the difference between SRP and OCP?
SRP ensures a class has one clear responsibility. OCP allows new functionality to be added without repeatedly modifying existing, stable code.

Q3. What does "one reason to change" mean in SRP?
A class should be responsible for one cohesive area of functionality. If that responsibility changes, the class may need modification.

Q4. How do we implement OCP in Python?
Using abstraction, abstract base classes, inheritance and polymorphism to create extensible designs.

Q5. What is polymorphism?
It lets different objects respond to the same method call in their own ways.

Q6. What happens when LSP is violated?
A child object may cause unexpected errors or incorrect behavior when used in place of its parent object.

Q7. Is a Square a Rectangle? Why can it violate LSP?
Mathematically yes. But if a Rectangle lets width and height change independently, a Square that forces them to stay equal violates the expected behavior of that implementation.

Q8. Are SOLID principles only for Java?
No. They apply to object-oriented design in Python, Java, C++, C# and other languages, and their ideas also help when designing larger application architectures.

---

9. 🧪 Test Your Understanding!

Try these before peeking at the answers! ❤️

1. A class handles user registration, database operations and email sending. Which principle is violated?

   • A) OCP
   • B) SRP
   • C) LSP

2. You add Google Pay by creating a new payment class without modifying PaymentService. Which principle are you following?

   • A) SRP
   • B) LSP
   • C) OCP

3. A Penguin inherits from Bird, but the parent promises every bird can fly. Which principle is violated?

   • A) LSP
   • B) OCP
   • C) SRP

4. Different payment classes implement the same pay() method differently. What OOP concept is this?

   • A) Encapsulation
   • B) Polymorphism
   • C) Normalization

5. A child class requires stricter input conditions than its parent method. Which principle may be violated?

   • A) SRP
   • B) OCP
   • C) LSP

👀 Click to reveal answers

1. B: SRP. The class has several unrelated reasons to change
2. C: OCP. You extended the system without modifying existing code
3. A: LSP. The child can't honor the parent's behavioral contract
4. B: Polymorphism. One interface, many implementations
5. C: LSP. Strengthening preconditions breaks substitutability

---

10. 📝 Final Revision Notes

• 🅢 Single Responsibility Principle: one class = one clear responsibility = one main reason to change
• 🅞 Open/Closed Principle: open for extension, closed for unnecessary modification
• 🅛 Liskov Substitution Principle: child objects must be safely usable wherever their parent objects are expected

💡 Don't just memorize the definitions. Whenever you write a FastAPI service, repository, model or authentication module, ask yourself:

1. Is this class doing too many jobs?
2. Can I add a new feature without rewriting existing logic?
3. If I inherit from another class, will my child class preserve its expected behavior?

That's how you start thinking like a software engineer, not just someone who writes code. 🧠

---

If this post helped you, drop a ❤️ or 🦄 and share it with a friend learning software design. Happy coding! 👩‍💻✨