Object-oriented design principles in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Single Responsibility Principle (SRP)

Which of the following best describes the Single Responsibility Principle in object-oriented design?

A A class should have only one reason to change, meaning it should have only one job or responsibility.

B A class should inherit from multiple classes to reuse code efficiently.

C A class should expose all its data members publicly for easy access.

D A class should handle multiple unrelated functionalities to reduce the number of classes.

💡 Hint

Think about how many reasons a class should have to change.

The Single Responsibility Principle states that a class should have only one reason to change, meaning it should focus on a single responsibility or job. This keeps classes simple and easier to maintain.

❓ Architecture

intermediate

Applying Open/Closed Principle (OCP)

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

A Modify the existing payment class each time a new payment method is added.

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

C Create a new class for each payment method that inherits from a common payment interface.

D Combine all payment methods into a single class with many conditional statements.

💡 Hint

Consider how to add new features without changing existing code.

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

❓ scaling

advanced

Scaling with Liskov Substitution Principle (LSP)

In a large system, you have a base class Vehicle and subclasses like Car and ElectricCar. Which design choice violates the Liskov Substitution Principle?

A <code>ElectricCar</code> overrides a method from <code>Vehicle</code> but throws an exception when called.

B <code>ElectricCar</code> inherits from <code>Car</code> and uses all inherited methods correctly.

C <code>Car</code> extends <code>Vehicle</code> and adds new methods specific to cars.

D All subclasses can be used wherever <code>Vehicle</code> is expected without altering program correctness.

💡 Hint

Think about substituting subclasses without breaking the program.

The Liskov Substitution Principle requires that subclasses can replace their base classes without affecting correctness. Throwing exceptions in overridden methods breaks this rule.

❓ tradeoff

advanced

Tradeoffs in Interface Segregation Principle (ISP)

Which scenario best illustrates a violation of the Interface Segregation Principle?

A Multiple small interfaces are created for specific client needs.

B A client class depends on an interface with many methods it does not use.

C A class implements only the methods it requires from an interface.

D Interfaces are designed to be minimal and focused on single responsibilities.

💡 Hint

Consider how clients should depend on interfaces.

The Interface Segregation Principle states that clients should not be forced to depend on interfaces they do not use. Large interfaces with unused methods violate this principle.

❓ estimation

expert

Estimating Impact of Violating Dependency Inversion Principle (DIP)

In a layered system, high-level modules directly depend on low-level modules instead of abstractions. What is the most likely impact of this design choice?

A High-level modules can be reused independently without any changes.

B The system becomes more flexible and easier to maintain due to direct dependencies.

C Low-level modules automatically adapt to changes in high-level modules.

D The system becomes tightly coupled, making it hard to change or extend low-level modules without affecting high-level modules.

💡 Hint

Think about coupling and flexibility between layers.

The Dependency Inversion Principle encourages depending on abstractions, not concrete implementations. Direct dependency on low-level modules causes tight coupling and reduces flexibility.