SOLID principles in Software Engineering - Full Explanation

Introduction

Building software can get complicated quickly, making it hard to change or fix later. The SOLID principles help programmers write code that is easier to understand, maintain, and improve over time.

Explanation

Single Responsibility Principle (SRP)

Each part of the code should have only one job or reason to change. This means a class or module should focus on just one task, making it simpler and less likely to break when changes happen.

A class should have only one responsibility to keep code clear and manageable.

Open/Closed Principle (OCP)

Software should be open to adding new features but closed to changing existing code. This means you can extend how things work without rewriting what already works well, reducing bugs.

You can add new behavior without changing existing code.

Liskov Substitution Principle (LSP)

Objects of a parent type should be replaceable with objects of a child type without breaking the program. This ensures that new parts fit smoothly where old parts were used.

Subtypes must work in place of their base types without errors.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use. Instead of one big interface, it's better to have many small, specific ones so that parts only know what they need.

Use many small interfaces tailored to specific needs, not one large interface.

Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules directly. Both should depend on abstractions. This means code depends on ideas or contracts, not on specific details, making it easier to change parts independently.

Depend on abstractions, not on concrete details.

Real World Analogy

Imagine building a house where each worker has a clear job, like plumbing or painting. You can add new rooms without changing the existing ones, and you can replace a painter with another without problems. Each worker only needs the tools for their job, and the manager gives instructions based on plans, not on how each tool works.

Single Responsibility Principle (SRP) → Each worker having one clear job, like only painting or only plumbing

Open/Closed Principle (OCP) → Adding new rooms to the house without changing the existing rooms

Liskov Substitution Principle (LSP) → Replacing one painter with another without affecting the work

Interface Segregation Principle (ISP) → Workers only needing the tools and instructions for their specific job

Dependency Inversion Principle (DIP) → The manager giving instructions based on plans, not on how each tool works

Diagram

Diagram

┌─────────────────────────────┐
│          SOLID Principles    │
├─────────────┬───────────────┤
│ SRP         │ One job only   │
├─────────────┼───────────────┤
│ OCP         │ Add without    │
│             │ changing      │
├─────────────┼───────────────┤
│ LSP         │ Replace child  │
│             │ without issues │
├─────────────┼───────────────┤
│ ISP         │ Small specific │
│             │ interfaces    │
├─────────────┼───────────────┤
│ DIP         │ Depend on     │
│             │ abstractions  │
└─────────────┴───────────────┘

A table showing each SOLID principle with its simple key idea.

Key Facts

Single Responsibility Principle → A class should have only one reason to change.

Open/Closed Principle → Software entities should be open for extension but closed for modification.

Liskov Substitution Principle → Subtypes must be substitutable for their base types without errors.

Interface Segregation Principle → Clients should not be forced to depend on interfaces they do not use.

Dependency Inversion Principle → Depend on abstractions, not on concrete implementations.

Common Confusions

Believing SRP means one class should do only one line of code.

Believing SRP means one class should do only one line of code. SRP means one class should have one reason to change, not that it must be extremely small.

Thinking OCP means never changing any code.

Thinking OCP means never changing any code. OCP means you should avoid changing existing code when adding features, but fixing bugs or improving code is allowed.

Assuming DIP means avoiding all direct dependencies.

Assuming DIP means avoiding all direct dependencies. DIP means depending on abstractions (like interfaces), not that dependencies are completely removed.

Summary

SOLID principles guide writing code that is easier to maintain and extend by focusing on clear responsibilities and good structure.

Each principle addresses a specific way to reduce problems when software grows or changes.

Using SOLID helps teams build software that adapts well to new needs without breaking existing features.

Practice

1. Which of the following best describes the Single Responsibility Principle (SRP) in SOLID?

easy

A. A class should have only one reason to change.

B. A class should inherit from multiple classes.

C. Functions should have multiple responsibilities.

D. Objects should be tightly coupled.

Solution

1. Step 1: Understand SRP definition

   The Single Responsibility Principle states that a class should have only one reason to change, meaning it should have one job or responsibility.

2. Step 2: Evaluate options

   A class should have only one reason to change.: A class should have only one reason to change. matches this definition exactly. Options B, C, and D contradict the principle by suggesting multiple responsibilities or tight coupling.

3. Final Answer:

   A class should have only one reason to change. -> Option A

4. Quick Check:

   SRP = One responsibility [OK]

Hint: SRP means one class, one job only [OK]

Common Mistakes:

• Thinking SRP allows multiple responsibilities
• Confusing SRP with inheritance rules
• Believing tight coupling is allowed

2. Which of the following is the correct syntax to express the Open/Closed Principle (OCP)?

easy

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

B. Software entities should be closed for both extension and modification.

C. Software entities should be open for both extension and modification.

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

Solution

1. Step 1: Recall OCP definition

   The Open/Closed Principle states that software entities should be open for extension but closed for modification, meaning you can add new features without changing existing code.

2. Step 2: Match options to definition

   Software entities should be open for extension but closed for modification.: Software entities should be open for extension but closed for modification. correctly states this principle. Software entities should be open for modification but closed for extension. reverses the terms, and options B and D contradict the principle.

3. Final Answer:

   Software entities should be open for extension but closed for modification. -> Option D

4. Quick Check:

   OCP = Open extension, closed modification [OK]

Hint: OCP means add features, don't change old code [OK]

Common Mistakes:

• Mixing up 'open for extension' and 'open for modification'
• Thinking OCP allows changing existing code freely
• Confusing OCP with SRP

3. Consider this code snippet applying the Liskov Substitution Principle (LSP):

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

class Penguin(Bird):
    def fly(self):
        return "Cannot fly"

bird = Bird()
penguin = Penguin()
print(bird.fly())
print(penguin.fly())

What is the output of this code?

medium

A. "Flying" followed by "Cannot fly"

B. "Flying" followed by "Flying"

C. Runtime error due to method override

D. "Cannot fly" followed by "Flying"

Solution

1. Step 1: Analyze Bird and Penguin classes

   Bird has a fly method returning "Flying". Penguin overrides fly to return "Cannot fly".

2. Step 2: Check print statements output

   bird.fly() returns "Flying". penguin.fly() returns "Cannot fly". So output is two lines: "Flying" then "Cannot fly".

3. Final Answer:

   "Flying" followed by "Cannot fly" -> Option A

4. Quick Check:

   bird.fly() = Flying, penguin.fly() = Cannot fly [OK]

Hint: Overridden methods can change output but not cause errors [OK]

Common Mistakes:

• Assuming penguin.fly() returns "Flying"
• Expecting runtime error from override
• Confusing method outputs order

4. Identify the error in this code violating the Interface Segregation Principle (ISP):

class WorkerInterface:
    def work(self): pass
    def eat(self): pass

class Robot(WorkerInterface):
    def work(self):
        print("Working")
    def eat(self):
        raise Exception("Robots don't eat")

medium

A. Robot class must implement eat() with a print statement.

B. WorkerInterface should have only one method.

C. Robot class should not implement eat() if it doesn't apply.

D. No error; this code follows ISP.

Solution

1. Step 1: Understand ISP

   Interface Segregation Principle says clients should not be forced to depend on methods they do not use.

2. Step 2: Analyze Robot class

   Robot implements eat() but raises an exception because it doesn't eat. This violates ISP because Robot is forced to implement an irrelevant method.

3. Final Answer:

   Robot class should not implement eat() if it doesn't apply. -> Option C

4. Quick Check:

   ISP forbids unused methods in interfaces [OK]

Hint: ISP means no forced unused methods [OK]

Common Mistakes:

• Thinking raising exception is acceptable
• Believing interface must have only one method
• Assuming no error if code runs

5. You have a payment system where new payment methods are added frequently. Which SOLID principle helps you design the system so you can add new payment types without changing existing code?

hard

A. Single Responsibility Principle

B. Open/Closed Principle

C. Liskov Substitution Principle

D. Dependency Inversion Principle

Solution

1. Step 1: Identify the problem

   The system needs to add new payment methods often without modifying existing code.

2. Step 2: Match with SOLID principles

   The Open/Closed Principle states software should be open for extension but closed for modification, exactly fitting this need.

3. Final Answer:

   Open/Closed Principle -> Option B

4. Quick Check:

   OCP = Add features without changing old code [OK]

Hint: OCP = add new without changing old [OK]

Common Mistakes:

• Confusing SRP with OCP
• Thinking LSP controls adding new types
• Assuming Dependency Inversion solves this