Applying SOLID to real code in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to apply the Single Responsibility Principle by separating concerns.

LLD

class UserManager:
    def __init__(self, user_repository):
        self.user_repository = user_repository

    def [1](self, user):
        self.user_repository.save(user)

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

Asave_user

Bdelete_user

Cupdate_user

Dget_user

Attempts:

3 left

💡 Hint

Common Mistakes

Using a generic method name that mixes multiple responsibilities.

Naming the method something unrelated to saving.

The method name save_user clearly indicates the responsibility of saving a user, aligning with the Single Responsibility Principle.

2fill in blank

medium

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

LLD

class NotificationSender:
    def send(self, message):
        [1]

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

Apass

Bprint('Send notification')

Creturn None

Draise NotImplementedError()

Attempts:

3 left

💡 Hint

Common Mistakes

Leaving the method empty with pass, which does not enforce implementation.

Returning None, which silently ignores the missing implementation.

Raising NotImplementedError enforces that subclasses must implement the send method, allowing extension without modifying the base class.

3fill in blank

hard

Fix the error in the code to comply with the Liskov Substitution Principle.

LLD

class Bird:
    def fly(self):
        print('Flying')

class Penguin(Bird):
    def [1](self):
        print('Swimming')

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

Afly

Bwalk

Cswim

Drun

Attempts:

3 left

💡 Hint

Common Mistakes

Overriding fly to raise an exception, breaking substitutability.

Not providing alternative behavior for Penguin.

Penguins cannot fly, so overriding fly to raise an exception violates Liskov Substitution Principle. Instead, define a new method swim for Penguin.

4fill in blank

hard

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

LLD

class PrinterInterface:
    def print_document(self):
        pass

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

class MultiFunctionDevice(PrinterInterface, ScannerInterface):
    def print_document(self):
        print('Printing')
    def [2](self):
        print('Scanning')

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

Ascan_document

Bfax_document

Ccopy_document

Dsend_email

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated method names that do not represent scanning.

Mixing fax or email methods which are not part of scanning.

Splitting interfaces into PrinterInterface and ScannerInterface allows clients to depend only on methods they use. Both blanks use scan_document to define scanning behavior.

5fill in blank

hard

Fill all three blanks to apply the Dependency Inversion Principle by depending on abstractions.

LLD

class DatabaseInterface:
    def [1](self, data):
        pass

class MySQLDatabase(DatabaseInterface):
    def [2](self, data):
        print(f"Saving {data} to MySQL")

class DataManager:
    def __init__(self, db: DatabaseInterface):
        self.db = db
    def save(self, data):
        self.db.[3](data)

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

Asave_data

Bsave

Cstore

Dinsert

Attempts:

3 left

💡 Hint

Common Mistakes

Using different method names causing mismatch.

Calling concrete class methods directly instead of interface methods.

By defining and using the save method in the abstraction and implementation, DataManager depends on the interface, not the concrete class, following the Dependency Inversion Principle.

Practice

1. Which SOLID principle encourages a class to have only one reason to change?

easy

A. Dependency Inversion Principle

B. Open/Closed Principle

C. Liskov Substitution Principle

D. Single Responsibility Principle

Solution

1. Step 1: Understand the principle names

   Single Responsibility Principle means one class should do one job only.

2. Step 2: Match principle to description

   Only Single Responsibility Principle talks about one reason to change.

3. Final Answer:

   Single Responsibility Principle -> Option D

4. Quick Check:

   One class, one reason to change = Single Responsibility Principle [OK]

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

Common Mistakes:

• Confusing Single Responsibility with Open/Closed
• Thinking Dependency Inversion means single responsibility
• Mixing Liskov Substitution with class responsibilities

2. Which of the following code snippets correctly applies the Dependency Inversion Principle?

easy

A. class Car { Engine engine = new Engine(); }

B. interface Engine { void start(); } class Car { Engine engine; Car(Engine e) { engine = e; } }

C. class Car { void start() { Engine engine = new Engine(); engine.start(); } }

D. class Engine { void start() {} } class Car extends Engine {}

Solution

1. Step 1: Identify Dependency Inversion Principle

   It says depend on abstractions (interfaces), not concrete classes.

2. Step 2: Check which code uses interfaces

   interface Engine { void start(); } class Car { Engine engine; Car(Engine e) { engine = e; } } uses interface Engine and injects it into Car, following DIP.

3. Final Answer:

   Interface with injection to depend on abstraction -> Option B

4. Quick Check:

   Depend on interface, not concrete class = DIP [OK]

Hint: Look for interface usage and constructor injection [OK]

Common Mistakes:

• Creating concrete objects inside classes (violates DIP)
• Extending concrete classes instead of using interfaces
• Not using constructor or setter injection

3. Given this code snippet, what will be the output?

interface Shape { double area(); }
class Rectangle implements Shape {
  double width, height;
  Rectangle(double w, double h) { width = w; height = h; }
  public double area() { return width * height; }
}
class Circle implements Shape {
  double radius;
  Circle(double r) { radius = r; }
  public double area() { return 3.14 * radius * radius; }
}
class AreaCalculator {
  double totalArea(Shape[] shapes) {
    double total = 0;
    for (Shape s : shapes) total += s.area();
    return total;
  }
}
public class Main {
  public static void main(String[] args) {
    Shape[] shapes = { new Rectangle(2,3), new Circle(1) };
    System.out.println(new AreaCalculator().totalArea(shapes));
  }
}

medium

A. 9.14

B. 12.14

C. 15.42

D. Error at runtime

Solution

1. Step 1: Calculate Rectangle area

   Rectangle area = 2 * 3 = 6

2. Step 2: Calculate Circle area

   Circle area = 3.14 * 1 * 1 = 3.14

3. Step 3: Sum areas

   Total area = 6 + 3.14 = 9.14

4. Final Answer:

   9.14 -> Option A

5. Quick Check:

   6 + 3.14 = 9.14 [OK]

Hint: Add areas of shapes using interface method calls [OK]

Common Mistakes:

• Using wrong formula for circle area
• Adding radius instead of area
• Forgetting to sum both shapes

4. Identify the violation of the Open/Closed Principle in this code:

class Report {
  void printReport(String type) {
    if (type.equals("PDF")) { System.out.println("Printing PDF"); }
    else if (type.equals("HTML")) { System.out.println("Printing HTML"); }
  }
}

medium

A. Adding new report types requires changing printReport method

B. Using if-else is always correct for Open/Closed Principle

C. The class is closed for modification

D. The method uses polymorphism correctly

Solution

1. Step 1: Understand Open/Closed Principle

   Classes should be open for extension but closed for modification.

2. Step 2: Analyze printReport method

   Adding new types means editing if-else, so modifying existing code.

3. Final Answer:

   Adding new report types requires changing printReport method -> Option A

4. Quick Check:

   Modifying code to add features breaks Open/Closed Principle [OK]

Hint: If adding features needs code change, Open/Closed is violated [OK]

Common Mistakes:

• Thinking if-else is always fine
• Confusing Open/Closed with Single Responsibility
• Ignoring need for polymorphism

5. You have a payment system with classes for CreditCardPayment and PayPalPayment. To follow the Interface Segregation Principle, how should you design the interfaces?

hard

A. Create one large interface Payment with all methods for all payment types

B. Make CreditCardPayment inherit from PayPalPayment

C. Create separate interfaces like CreditCardPaymentInterface and PayPalPaymentInterface with only relevant methods

D. Use a single abstract class with all payment methods implemented

Solution

1. Step 1: Understand Interface Segregation Principle

   Clients should not depend on methods they do not use; interfaces should be small and specific.

2. Step 2: Apply to payment system

   Separate interfaces for each payment type avoid forcing classes to implement unused methods.

3. Final Answer:

   Create separate interfaces like CreditCardPaymentInterface and PayPalPaymentInterface with only relevant methods -> Option C

4. Quick Check:

   Small, specific interfaces = Interface Segregation Principle [OK]

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

Common Mistakes:

• Using one big interface for all payment types
• Inheriting unrelated payment classes
• Using abstract class forcing all methods