Applying SOLID to real code in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Which SOLID principle is demonstrated by splitting a large class into smaller classes each handling a single responsibility?

Consider a large class that handles user authentication, logging, and data validation. Splitting this class into three separate classes, each focusing on one task, best demonstrates which SOLID principle?

A Single Responsibility Principle

B Open/Closed Principle

C Liskov Substitution Principle

D Dependency Inversion Principle

💡 Hint

Think about the principle that encourages one class to have only one reason to change.

The Single Responsibility Principle states that a class should have only one reason to change, meaning it should have only one job or responsibility. Splitting a large class into smaller focused classes follows this principle.

❓ Architecture

intermediate

How does the Open/Closed Principle improve system extensibility?

You have a payment processing system that needs to support new payment methods without changing existing code. Which design approach best follows the Open/Closed Principle?

A Write all payment logic in a single method with many if-else conditions

B Modify the existing payment class to add new methods for each payment type

C Use global variables to switch payment methods dynamically

D Create new classes implementing a common payment interface for each new payment method

💡 Hint

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

The Open/Closed Principle states that software entities should be open for extension but closed for modification. Creating new classes implementing a common interface allows adding new payment methods without changing existing code.

❓ scaling

advanced

Which SOLID principle helps avoid runtime errors when replacing objects with their subclasses?

In a system where subclasses replace parent classes, which SOLID principle ensures that the system behaves correctly without unexpected errors?

A Single Responsibility Principle

B Liskov Substitution Principle

C Dependency Inversion Principle

D Interface Segregation Principle

💡 Hint

Consider the principle that focuses on substitutability of objects.

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. This avoids runtime errors due to unexpected behavior.

❓ tradeoff

advanced

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

Applying the Interface Segregation Principle often leads to creating many small interfaces. What is a potential downside of this approach?

A Higher risk of runtime errors

B Reduced flexibility in implementing classes

C Increased complexity due to many interfaces to manage

D Difficulty in extending system functionality

💡 Hint

Think about managing many small pieces instead of fewer large ones.

While the Interface Segregation Principle improves modularity by splitting interfaces, it can increase complexity because developers must manage many small interfaces, which can be harder to organize.

❓ component

expert

In a layered architecture, how does the Dependency Inversion Principle improve maintainability?

Consider a system with high-level modules depending on low-level modules directly. How does applying the Dependency Inversion Principle change this dependency to improve maintainability?

A High-level modules depend on abstractions, not on low-level modules

B Low-level modules depend on high-level modules to reduce coupling

C Both high-level and low-level modules depend on concrete implementations

D Remove abstractions to simplify dependencies

💡 Hint

Think about reversing the direction of dependencies using interfaces or abstractions.

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules directly; both should depend on abstractions. This reduces coupling and improves maintainability by allowing changes in low-level modules without affecting high-level modules.

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