SOLID violations and fixes in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying Single Responsibility Principle Violation

Which of the following class designs violates the Single Responsibility Principle (SRP)?

A A class that handles both user authentication and logging user activities.

B A class that only manages user profile data.

C A class dedicated solely to sending email notifications.

D A class that only formats data for display.

💡 Hint

SRP means a class should have only one reason to change.

Option A mixes authentication and logging, which are two different responsibilities. This violates SRP.

❓ Architecture

intermediate

Fixing Open/Closed Principle Violation

You have a payment processing system that requires modifying existing classes to add new payment methods. Which design change best fixes this Open/Closed Principle (OCP) violation?

A Use global variables to switch payment methods inside the existing class.

B Add new methods directly to the existing payment processing class.

C Create a PaymentMethod interface and implement new payment methods as separate classes.

D Duplicate the payment processing class for each new payment method.

💡 Hint

OCP means software entities should be open for extension but closed for modification.

Option C allows adding new payment methods without changing existing code, following OCP.

❓ scaling

advanced

Liskov Substitution Principle Violation Impact

Consider a class hierarchy where a subclass overrides a method but throws exceptions not expected by the base class. What problem does this cause in a large system?

A It breaks Liskov Substitution Principle, causing unexpected runtime errors when using polymorphism.

B It improves performance by handling errors locally.

C It simplifies the base class by moving complexity to subclasses.

D It ensures better encapsulation and hides implementation details.

💡 Hint

Liskov Substitution Principle requires subclasses to be replaceable without altering correctness.

Throwing unexpected exceptions breaks substitutability, causing runtime errors.

❓ tradeoff

advanced

Interface Segregation Principle Tradeoff

Which option best describes a tradeoff when applying Interface Segregation Principle (ISP) strictly in a system with many small interfaces?

A It decreases modularity by merging multiple responsibilities.

B Increased number of interfaces can lead to complexity in managing dependencies.

C It reduces code readability by combining unrelated methods.

D It forces all clients to implement large interfaces even if they use few methods.

💡 Hint

ISP encourages small, client-specific interfaces.

While ISP improves modularity, too many small interfaces can increase dependency management complexity.

❓ estimation

expert

Estimating Impact of Dependency Inversion Principle Violation

A system tightly couples high-level modules directly to low-level modules without abstractions. What is the most significant impact on system maintainability and scalability?

A It allows easier replacement of low-level modules without affecting high-level modules.

B It improves performance by avoiding abstraction overhead.

C It simplifies testing by reducing the number of interfaces.

D Changes in low-level modules require changes in high-level modules, increasing maintenance effort.

💡 Hint

Dependency Inversion Principle promotes depending on abstractions, not concretions.

Tight coupling causes ripple effects of changes, making maintenance and scaling harder.

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