SOLID principles in Software Engineering - Mini Project: Build & Apply

Understanding SOLID Principles

📖 Scenario: You are learning about the SOLID principles, which help software developers write better, easier-to-maintain code. These principles guide how to organize code in a way that is clear and flexible.

🎯 Goal: Build a simple example that shows each of the five SOLID principles with clear, easy-to-understand code snippets and explanations.

📋 What You'll Learn

Create a simple class example for each SOLID principle

Add a short explanation for each principle

Use clear and simple code structure

Show how each principle improves code design

💡 Why This Matters

🌍 Real World

SOLID principles help developers write code that is easier to maintain, extend, and understand in real software projects.

💼 Career

Understanding SOLID is essential for software engineers to create high-quality, professional code and work effectively in teams.

1

Create a class example for Single Responsibility Principle (SRP)

Write a class called Book that has a method get_title returning the book's title. This class should only handle book data, not printing or saving.

Software Engineering

# Write the Book class with a get_title method
# Your code here

Hint

Keep the class focused on just storing and returning the book title.

2

Add a helper class for Open/Closed Principle (OCP)

Create a class called DiscountCalculator with a method calculate that returns a price after discount. Add a variable discount_rate set to 0.1 (10%).

Software Engineering

class Book:
    def __init__(self, title):
        self.title = title
    
    def get_title(self):
        return self.title

# Create DiscountCalculator class with discount_rate and calculate method
# Your code here

Hint

This class can be extended later without changing existing code.

3

Implement Liskov Substitution Principle (LSP) with shape classes

Create a base class Shape with a method area that returns 0. Then create a subclass Square that overrides area to return side * side. Use side as an attribute.

Software Engineering

class Book:
    def __init__(self, title):
        self.title = title
    
    def get_title(self):
        return self.title

class DiscountCalculator:
    discount_rate = 0.1
    
    def calculate(self, price):
        return price * (1 - self.discount_rate)

# Create Shape base class with area method returning 0
# Create Square subclass with side attribute and area method
# Your code here

Hint

Subclasses should be usable wherever the base class is expected.

4

Demonstrate Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP)

Create two classes: Printer with method print_document and Scanner with method scan_document. Then create a class AllInOneMachine that uses instances of Printer and Scanner to perform printing and scanning.

Software Engineering

class Book:
    def __init__(self, title):
        self.title = title
    
    def get_title(self):
        return self.title

class DiscountCalculator:
    discount_rate = 0.1
    
    def calculate(self, price):
        return price * (1 - self.discount_rate)

class Shape:
    def area(self):
        return 0

class Square(Shape):
    def __init__(self, side):
        self.side = side
    
    def area(self):
        return self.side * self.side

# Create Printer class with print_document method
# Create Scanner class with scan_document method
# Create AllInOneMachine class that uses Printer and Scanner instances
# Your code here

Hint

Separate interfaces for different functions and depend on abstractions.

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