Program to interface not implementation in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why prefer programming to an interface rather than an implementation?

Imagine you want to build a remote control for different TV brands. Why is it better to design the remote control to work with a general TV interface instead of a specific TV brand's implementation?

A Because programming to an interface allows the remote to work with any TV brand that follows the interface, making it flexible and easy to extend.

B Because programming to an implementation makes the remote control faster and more efficient for one TV brand only.

C Because programming to an interface requires more code and is harder to maintain.

D Because programming to an implementation avoids the need for interfaces and reduces complexity.

💡 Hint

Think about how many different TV brands you want your remote to control without changing the remote itself.

Programming to an interface means the remote control depends on a general contract (interface) that all TVs follow. This allows the remote to work with any TV brand that implements the interface, making the system flexible and easy to extend without changing the remote.

❓ Architecture

intermediate

Identify the correct design for a payment system using program to interface principle

You are designing a payment system that supports multiple payment methods like credit card, PayPal, and bank transfer. Which design best follows the 'program to interface, not implementation' principle?

A Define a PaymentMethod interface with a pay() method, and implement this interface for each payment type. The system uses PaymentMethod references only.

B Write separate classes for each payment type and call their specific methods directly without any common interface.

C Use a single PaymentProcessor class that contains all payment logic for every payment type inside it.

D Create a PaymentMethod abstract class but use concrete classes directly in the system without interface references.

💡 Hint

Think about how the system can add new payment types without changing existing code.

Defining a PaymentMethod interface and programming to it allows the system to treat all payment types uniformly. New payment methods can be added by implementing the interface without changing the system code, following the open-closed principle.

❓ scaling

advanced

Scaling a notification system using program to interface principle

You have a notification system that sends messages via email, SMS, and push notifications. To scale and add new notification types easily, which approach best applies the 'program to interface' principle?

A Create separate classes for each notification type but do not use a common interface or base class.

B Hardcode the logic for each notification type inside a single NotificationService class.

C Create a NotificationSender interface with a send() method. Implement this interface for each notification type. The system uses NotificationSender references to send messages.

D Use concrete classes directly and call their methods without any interface abstraction.

💡 Hint

Consider how adding a new notification type affects existing code.

Using a NotificationSender interface allows the system to treat all notification types uniformly. Adding new notification types requires only implementing the interface without modifying existing code, which supports scalability and maintainability.

❓ tradeoff

advanced

Tradeoffs when programming to interface instead of implementation

What is a common tradeoff when choosing to program to an interface rather than a concrete implementation?

A It always improves performance but makes the code harder to understand.

B It may introduce slight performance overhead due to indirection but improves flexibility and maintainability.

C It reduces code size significantly but limits future extensions.

D It removes the need for testing because interfaces guarantee correctness.

💡 Hint

Think about the cost of abstraction versus benefits.

Programming to an interface adds a layer of abstraction that can cause minor performance overhead due to indirection. However, this tradeoff is worthwhile because it makes the system more flexible and easier to maintain or extend.

❓ component

expert

Design component interaction using program to interface principle

You are designing a modular logging system where different modules can log messages to various outputs (console, file, remote server). How should components interact to follow the 'program to interface' principle?

A Modules implement their own logging logic without using shared interfaces or components.

B Modules directly instantiate concrete logger classes and call their log methods.

C Modules send log messages to a global logging function without any interface abstraction.

D Define a Logger interface with a log(message) method. Modules depend only on Logger interface references, and concrete loggers implement this interface.

💡 Hint

Consider how modules can switch logging outputs without changing their code.

By defining a Logger interface and programming modules to it, the system allows swapping or adding new logging outputs without modifying module code. This decouples modules from concrete implementations and supports modularity and extensibility.