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.