SOLID principles in Software Engineering - Step-by-Step Execution

Concept Flow - SOLID principles

Start: Design a Class

↓

S: Single Responsibility

↓

O: Open/Closed

↓

L: Liskov Substitution

↓

I: Interface Segregation

↓

D: Dependency Inversion

↓

Better Software Design

The SOLID principles guide step-by-step improvements to class design for better software structure.

Execution Sample

Software Engineering

class Bird {
  fly() {}
}

class Penguin extends Bird {
  fly() { throw new Error('Cannot fly'); }
}

Shows a violation of Liskov Substitution: Penguin cannot replace Bird because it cannot fly.

Analysis Table

Step	Principle	Check	Result	Action
1	Single Responsibility	Does class have one reason to change?	Yes	Keep class focused
2	Open/Closed	Can class be extended without modification?	No	Refactor to allow extension
3	Liskov Substitution	Can subclass replace superclass without errors?	No	Fix subclass behavior
4	Interface Segregation	Are interfaces client-specific and minimal?	No	Split interfaces
5	Dependency Inversion	Do high-level modules depend on abstractions?	No	Introduce abstractions
6	End	All principles checked	Improved design	Apply principles in code

💡 All SOLID principles checked to improve software design quality.

State Tracker

Principle	Initial Status	After Applying Principle	Final Status
Single Responsibility	Multiple reasons to change	One reason to change	Focused class
Open/Closed	Modifications needed for new features	Extendable without changes	Stable extension
Liskov Substitution	Subclass breaks behavior	Subclass compatible	Reliable inheritance
Interface Segregation	Fat interfaces	Small, client-specific interfaces	Clear contracts
Dependency Inversion	High-level depends on low-level	Both depend on abstractions	Flexible dependencies

Key Insights - 3 Insights

Why can't a Penguin class just inherit from Bird if it can't fly?

Because of Liskov Substitution (step 3 in execution_table), subclasses must behave like their parent. Penguin breaks this by throwing an error in fly(), so it violates the principle.

What does it mean for a class to have a single responsibility?

At step 1, Single Responsibility means a class should have only one reason to change. If it handles multiple tasks, changes in one task affect the whole class, making maintenance harder.

Why split interfaces instead of one big interface?

At step 4, Interface Segregation says clients should only depend on methods they use. Big interfaces force clients to implement unused methods, causing unnecessary complexity.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What problem does the Penguin class cause?

A It has too many responsibilities

B It cannot replace Bird without errors

C It depends on low-level modules

D It uses a fat interface

💡 Hint

Check the 'Result' column at step 3 about subclass replacement.

At which step does the design ensure classes can be extended without modifying existing code?

A Step 2

B Step 4

C Step 1

D Step 5

💡 Hint

Look for 'Open/Closed' principle in the execution_table.

If a class depends directly on concrete classes instead of abstractions, which principle is violated?

A Single Responsibility

B Liskov Substitution

C Dependency Inversion

D Interface Segregation

💡 Hint

Check step 5 about dependencies on abstractions.

Concept Snapshot

SOLID principles guide good class design:
S: Single Responsibility - one reason to change
O: Open/Closed - extend without modifying
L: Liskov Substitution - subclasses replace parents safely
I: Interface Segregation - small, client-specific interfaces
D: Dependency Inversion - depend on abstractions, not details

Full Transcript

The SOLID principles are five key rules to design software classes better. First, Single Responsibility means each class should have only one job. Next, Open/Closed says classes should be extendable without changing existing code. Liskov Substitution requires subclasses to behave like their parent classes so they can be used interchangeably. Interface Segregation advises splitting large interfaces into smaller ones so clients only use what they need. Finally, Dependency Inversion means high-level modules should depend on abstractions, not concrete details. Following these steps improves code quality and maintainability.

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