Why SOLID principles guide maintainable design in LLD - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Single Responsibility Principle (SRP)

Which option best describes the Single Responsibility Principle in system design?

A A class should inherit from multiple classes to reuse code efficiently.

B A class should depend on concrete implementations rather than abstractions.

C A class should have only one reason to change, meaning it should have only one job or responsibility.

D A class should handle all related functionalities to reduce the number of classes.

💡 Hint

Think about how many reasons a class should have to change.

The Single Responsibility Principle states that a class should have only one reason to change, which means it should focus on a single responsibility to keep the design simple and maintainable.

❓ Architecture

intermediate

Applying Open/Closed Principle (OCP) in Design

Which design approach best follows the Open/Closed Principle to allow system extension without modification?

A Duplicate existing code to add new features quickly.

B Modify existing classes directly whenever new features are needed.

C Avoid using abstractions and rely on concrete classes only.

D Use inheritance or interfaces to add new behaviors by extending existing classes without changing them.

💡 Hint

Think about how to add new features without changing existing code.

The Open/Closed Principle encourages designs where classes are open for extension but closed for modification, often achieved by using inheritance or interfaces.

❓ scaling

advanced

Scaling with Dependency Inversion Principle (DIP)

How does applying the Dependency Inversion Principle help in scaling a software system?

A By making both high-level and low-level modules depend on abstractions, reducing tight coupling and improving flexibility.

B By making high-level modules depend on low-level modules directly for faster execution.

C By removing abstractions to simplify the codebase.

D By tightly coupling modules to reduce the number of interfaces.

💡 Hint

Consider how dependencies affect flexibility and change management.

Dependency Inversion Principle states that high-level modules should not depend on low-level modules directly; both should depend on abstractions, which helps in scaling by making the system more flexible and easier to change.

❓ tradeoff

advanced

Tradeoffs of Interface Segregation Principle (ISP)

What is a common tradeoff when applying the Interface Segregation Principle in system design?

A Ignoring interfaces altogether simplifies the design.

B Creating many small interfaces can increase complexity but improves client-specific design.

C Using one large interface reduces complexity and improves flexibility.

D Forcing clients to implement unused methods reduces code clarity.

💡 Hint

Think about the balance between interface size and client needs.

Interface Segregation Principle encourages creating smaller, client-specific interfaces to avoid forcing clients to depend on methods they do not use, but this can lead to more interfaces to manage.

❓ component

expert

Identifying SOLID Violations in a Component Design

Given a component that handles user authentication, logging, and data validation all in one class, which SOLID principle is most violated?

A Single Responsibility Principle, because the class has multiple reasons to change.

B Liskov Substitution Principle, because subclasses cannot replace the parent class.

C Dependency Inversion Principle, because the class depends on abstractions.

D Open/Closed Principle, because the class is open for extension.

💡 Hint

Think about how many jobs the class is doing.

A class handling multiple unrelated responsibilities violates the Single Responsibility Principle, making it harder to maintain and modify.

Practice

1. Which of the following best describes the main goal of the SOLID principles in software design?

easy

A. To create code that is easy to understand, maintain, and extend

B. To make code run faster by using complex algorithms

C. To reduce the number of lines of code in a program

D. To enforce strict coding styles and formatting rules

Solution

1. Step 1: Understand the purpose of SOLID principles

   SOLID principles focus on writing code that is clean, flexible, and easy to maintain and extend over time.

2. Step 2: Compare options with the purpose

   To create code that is easy to understand, maintain, and extend matches this goal, while others focus on speed, code length, or style, which are not the main SOLID goals.

3. Final Answer:

   To create code that is easy to understand, maintain, and extend -> Option A

4. Quick Check:

   SOLID = Maintainable code [OK]

Hint: SOLID = clean, flexible, maintainable code [OK]

Common Mistakes:

• Confusing SOLID with performance optimization
• Thinking SOLID is about code formatting
• Believing SOLID reduces code length only

2. Which of the following is the correct description of the Single Responsibility Principle (SRP)?

easy

A. A class should be responsible for error logging only

B. A class should have only one reason to change

C. A class should handle all user interface and database logic

D. A class should inherit from multiple classes

Solution

1. Step 1: Recall the Single Responsibility Principle

   SRP states that a class should have only one reason to change, meaning it should have a single responsibility.

2. Step 2: Evaluate each option

   A class should have only one reason to change correctly states SRP. A class should inherit from multiple classes describes multiple inheritance, not SRP. A class should handle all user interface and database logic mixes responsibilities, violating SRP. A class should be responsible for error logging only is too narrow and not a general principle.

3. Final Answer:

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

4. Quick Check:

   SRP = One reason to change [OK]

Hint: SRP = one responsibility per class [OK]

Common Mistakes:

• Confusing SRP with inheritance rules
• Thinking SRP means one class per feature
• Believing SRP limits class functionality too much

3. Consider this code snippet following the Open/Closed Principle (OCP):

class Shape:
    def area(self):
        pass

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    def area(self):
        return 3.14 * self.radius * self.radius

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

shapes = [Circle(2), Square(3)]
areas = [shape.area() for shape in shapes]
print(areas)

What will be the output?

medium

A. [6.28, 9]

B. [12.56, 6]

C. Error: area method not implemented

D. [12.56, 9]

Solution

1. Step 1: Calculate area of Circle with radius 2

   Area = 3.14 * 2 * 2 = 12.56

2. Step 2: Calculate area of Square with side 3

   Area = 3 * 3 = 9

3. Step 3: Collect areas in list and print

   Output list is [12.56, 9]

4. Final Answer:

   [12.56, 9] -> Option D

5. Quick Check:

   Circle area + Square area = [12.56, 9] [OK]

Hint: Calculate each shape's area separately [OK]

Common Mistakes:

• Using wrong formula for circle area
• Mixing side length with radius
• Expecting error due to base class method

4. A developer wrote this code violating the Dependency Inversion Principle (DIP):

class Database:
    def connect(self):
        print('Connecting to MySQL')

class UserService:
    def __init__(self):
        self.db = Database()
    def get_user(self):
        self.db.connect()
        return 'User data'

What is the main problem here?

medium

A. UserService depends directly on a concrete Database class, making it hard to change database types

B. Database class should not have a connect method

C. UserService should not have a get_user method

D. Database connection should be established outside UserService

Solution

1. Step 1: Understand Dependency Inversion Principle

   DIP says high-level modules should depend on abstractions, not concrete classes.

2. Step 2: Analyze the code dependency

   UserService creates a concrete Database instance directly, tightly coupling them and making changes hard.

3. Final Answer:

   UserService depends directly on a concrete Database class, making it hard to change database types -> Option A

4. Quick Check:

   DIP = Depend on abstractions, not concretes [OK]

Hint: Check if high-level class depends on concrete class [OK]

Common Mistakes:

• Thinking connect method is wrong
• Confusing method placement with DIP violation
• Ignoring tight coupling issues

5. You are designing a payment system that must support multiple payment methods (credit card, PayPal, crypto). To follow the Interface Segregation Principle (ISP) and keep the system maintainable, which design approach is best?

hard

A. Use one class with many conditional statements to handle all payment types

B. Create a single large interface with all payment methods combined, and implement it in one class

C. Create separate interfaces for each payment method and implement only the needed ones in each class

D. Avoid interfaces and use global functions for each payment method

Solution

1. Step 1: Recall Interface Segregation Principle

   ISP states clients should not be forced to depend on interfaces they do not use; smaller, specific interfaces are better.

2. Step 2: Evaluate design options

   Create separate interfaces for each payment method and implement only the needed ones in each class creates separate interfaces per payment method, so classes implement only what they need, improving maintainability.

3. Final Answer:

   Create separate interfaces for each payment method and implement only the needed ones in each class -> Option C

4. Quick Check:

   ISP = Small, specific interfaces [OK]

Hint: Split interfaces by feature to avoid unused methods [OK]

Common Mistakes:

• Using one big interface for all methods
• Mixing all logic in one class with conditionals
• Ignoring interface design principles