SOLID violations and fixes in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to fix the Single Responsibility Principle violation by separating concerns.

LLD

class UserManager:
    def create_user(self, user_data):
        # code to create user
        pass

    def [1](self, user):
        # code to send welcome email
        pass

Drag options to blanks, or click blank then click option'

Asend_welcome_email

Bdelete_user

Cupdate_user

Dvalidate_user

Attempts:

3 left

💡 Hint

Common Mistakes

Keeping email sending logic inside UserManager class.

Naming methods unrelated to user management.

The method send_welcome_email should be moved to a separate class to follow Single Responsibility Principle.

2fill in blank

medium

Complete the code to fix the Open/Closed Principle violation by allowing extension without modification.

LLD

class Report:
    def generate(self, report_type):
        if report_type == 'pdf':
            return self.generate_pdf()
        elif report_type == 'csv':
            return self.generate_csv()

    def generate_pdf(self):
        pass

    def generate_csv(self):
        pass

class [1](Report):
    def generate_excel(self):
        pass

Drag options to blanks, or click blank then click option'

AReportService

BExcelReport

CReportGenerator

DReportManager

Attempts:

3 left

💡 Hint

Common Mistakes

Modifying the original Report class to add new report types.

Using generic class names that do not specify report type.

Creating a new subclass ExcelReport allows adding new report types without modifying the existing Report class, following Open/Closed Principle.

3fill in blank

hard

Fix the error in the code violating the Liskov Substitution Principle by correcting the method signature.

LLD

class Bird:
    def fly(self):
        pass

class Penguin(Bird):
    def [1](self, speed):
        # Penguins cannot fly, so this method should not accept parameters
        pass

Drag options to blanks, or click blank then click option'

Awalk(self)

Bfly(self, speed)

Cswim(self)

Dfly(self)

Attempts:

3 left

💡 Hint

Common Mistakes

Adding extra parameters in subclass methods.

Changing method names in subclass.

The subclass method fly must have the same signature as the superclass method to satisfy Liskov Substitution Principle.

4fill in blank

hard

Fill both blanks to fix the Interface Segregation Principle violation by splitting interfaces.

LLD

class [1]:
    def print_document(self, document):
        pass

class [2]:
    def scan_document(self, document):
        pass

Drag options to blanks, or click blank then click option'

APrinter

BScanner

CAllInOneMachine

DFaxMachine

Attempts:

3 left

💡 Hint

Common Mistakes

Using a single interface for all functions.

Naming interfaces too broadly.

Splitting into separate Printer and Scanner interfaces avoids forcing clients to depend on methods they do not use.

5fill in blank

hard

Fill all three blanks to fix the Dependency Inversion Principle violation by introducing abstractions.

LLD

class [1]:
    def connect(self):
        pass

class Database:
    def __init__(self, [2]):
        self.connection = [3]

    def query(self):
        self.connection.connect()

Drag options to blanks, or click blank then click option'

AConnectionInterface

Bconnection

Cdb_connection

DDatabaseConnection

Attempts:

3 left

💡 Hint

Common Mistakes

Directly depending on concrete connection classes.

Using inconsistent parameter names.

Using an abstraction ConnectionInterface and depending on it via the parameter connection in Database class follows Dependency Inversion Principle.

Practice

1. Which SOLID principle is violated if a class has too many responsibilities, making it hard to maintain?

easy

A. Single Responsibility Principle

B. Open/Closed Principle

C. Liskov Substitution Principle

D. Interface Segregation Principle

Solution

1. Step 1: Understand the problem of multiple responsibilities

   A class with many responsibilities is hard to maintain and change because changes in one responsibility may affect others.

2. Step 2: Identify the violated SOLID principle

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

3. Final Answer:

   Single Responsibility Principle -> Option A

4. Quick Check:

   One class, one responsibility = C [OK]

Hint: One class, one job means Single Responsibility Principle [OK]

Common Mistakes:

• Confusing Single Responsibility with Open/Closed Principle
• Thinking Liskov Substitution relates to responsibilities
• Mixing Interface Segregation with class responsibilities

2. Which of the following code snippets correctly applies the Open/Closed Principle by allowing extension without modification?
class Shape {
draw() { /* draw shape */ }
}
class Circle extends Shape {
draw() { /* draw circle */ }
}

easy

A. Adding new shape classes by extending Shape without changing existing code

B. Modifying the Shape class draw method to handle all shapes

C. Using a single class for all shapes with if-else inside draw

D. Changing Circle class to override Shape's draw method with new logic

Solution

1. Step 1: Understand Open/Closed Principle

   This principle says software entities should be open for extension but closed for modification.

2. Step 2: Analyze the code snippet

   Extending Shape with new classes like Circle adds new behavior without changing existing Shape code.

3. Final Answer:

   Adding new shape classes by extending Shape without changing existing code -> Option A

4. Quick Check:

   Extend without modify = A [OK]

Hint: Extend classes, don't change existing ones [OK]

Common Mistakes:

• Modifying base class instead of extending
• Using if-else inside methods to handle new cases
• Overriding methods incorrectly causing side effects

3. Given the following code violating Interface Segregation Principle, what is the output when calling robot.work()?

interface Worker {
  void work();
  void eat();
}
class Robot implements Worker {
  public void work() { System.out.println("Robot working"); }
  public void eat() { throw new UnsupportedOperationException(); }
}
Robot robot = new Robot();
robot.work();

medium

A. No output

B. UnsupportedOperationException thrown

C. Compilation error

D. Robot working

Solution

1. Step 1: Understand the code behavior

   The robot class implements work() by printing "Robot working" and eat() throws an exception.

2. Step 2: Analyze the method called

   Only robot.work() is called, which prints the message without error.

3. Final Answer:

   Robot working -> Option D

4. Quick Check:

   Calling work() prints message = A [OK]

Hint: Calling only implemented methods avoids exceptions [OK]

Common Mistakes:

• Assuming eat() is called causing exception
• Thinking interface violation causes compile error
• Ignoring method actually called in code

4. Identify the main problem in this code violating Liskov Substitution Principle:

class Bird {
  void fly() { System.out.println("Flying"); }
}
class Ostrich extends Bird {
  void fly() { throw new UnsupportedOperationException(); }
}

medium

A. Bird class should not have fly method

B. Ostrich should override fly with different signature

C. Ostrich cannot replace Bird without breaking behavior

D. No violation, code is correct

Solution

1. Step 1: Understand Liskov Substitution Principle

   Subtypes must be replaceable for their base types without altering correctness.

2. Step 2: Analyze Ostrich behavior

   Ostrich throws exception on fly(), breaking expected behavior of Bird.

3. Final Answer:

   Ostrich cannot replace Bird without breaking behavior -> Option C

4. Quick Check:

   Subtype must behave like base = B [OK]

Hint: Subtype must not break base class behavior [OK]

Common Mistakes:

• Thinking method signature change fixes violation
• Ignoring exception breaking substitution
• Assuming base class design is wrong here

5. You have a payment system where the PaymentProcessor interface has methods payWithCreditCard(), payWithPayPal(), and payWithCrypto(). A new payment method is added, but many classes implementing this interface do not support all methods, causing empty or error implementations. How should you fix this design following SOLID principles?

hard

A. Remove unsupported methods from implementations silently

B. Split the interface into smaller ones for each payment method

C. Keep one interface and add flags to check supported methods

D. Add default empty implementations to the interface methods

Solution

1. Step 1: Identify the violated principle

   Having one interface with many methods causes classes to implement unsupported methods, violating Interface Segregation Principle.

2. Step 2: Apply the fix

   Splitting the interface into smaller, specific interfaces lets classes implement only what they support, improving design.

3. Final Answer:

   Split the interface into smaller ones for each payment method -> Option B

4. Quick Check:

   Small interfaces, no unused methods = D [OK]

Hint: Use many small interfaces, not one big one [OK]

Common Mistakes:

• Adding empty default methods hides design flaws
• Using flags complicates code and violates design
• Removing methods silently breaks interface contract