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.

Practice

1. What is the main benefit of programming to an interface rather than a concrete implementation?

easy

A. It allows changing the implementation without affecting the code that uses it.

B. It makes the program run faster by using direct calls.

C. It reduces the number of lines of code needed.

D. It forces the use of only one implementation.

Solution

1. Step 1: Understand interface vs implementation

   Programming to an interface means using a contract that defines what methods are available, not how they work internally.

2. Step 2: Identify the benefit of this approach

   This allows swapping or changing the underlying implementation without changing the code that depends on the interface.

3. Final Answer:

   It allows changing the implementation without affecting the code that uses it. -> Option A

4. Quick Check:

   Interface abstraction = flexibility [OK]

Hint: Interfaces hide details, so implementations can change freely [OK]

Common Mistakes:

• Thinking it improves speed directly
• Believing it reduces code size automatically
• Assuming only one implementation is allowed

2. Which of the following code snippets correctly shows programming to an interface in a language like Java?

easy

A. List<String> list = new ArrayList<>();

B. ArrayList<String> list = new ArrayList<>();

C. List<String> list = new List<>();

D. ArrayList<String> list = new List<>();

Solution

1. Step 1: Identify interface and implementation

   In Java, List is an interface, and ArrayList is a concrete class implementing List.

2. Step 2: Check which declaration uses interface type

   Declaring the variable as List and instantiating with ArrayList means programming to interface, not implementation.

3. Final Answer:

   List<String> list = new ArrayList<>(); -> Option A

4. Quick Check:

   Variable type = interface [OK]

Hint: Use interface type on left side, implementation on right [OK]

Common Mistakes:

• Using concrete class on both sides
• Trying to instantiate an interface directly
• Mixing types incorrectly

3. Given the following code in a language supporting interfaces:

interface Vehicle { void drive(); }
class Car implements Vehicle { public void drive() { print("Car driving"); } }
class Bike implements Vehicle { public void drive() { print("Bike driving"); } }
Vehicle v = new Car();
v.drive();

What will be the output?

medium

A. Compilation error

B. Bike driving

C. Car driving

D. Vehicle driving

Solution

1. Step 1: Identify the object type assigned to interface variable

   The variable v of type Vehicle is assigned a new Car object.

2. Step 2: Determine which drive() method runs

   Calling v.drive() runs the Car's drive() method because the actual object is Car.

3. Final Answer:

   Car driving -> Option C

4. Quick Check:

   Interface variable calls actual object's method [OK]

Hint: Interface calls use actual object's method at runtime [OK]

Common Mistakes:

• Assuming interface method runs
• Confusing object type with variable type
• Expecting compilation error due to interface

4. Consider this code snippet:

interface Printer { void print(); }
class LaserPrinter implements Printer { void print() { System.out.println("Laser printing"); } }
Printer p = new LaserPrinter();
p.print();

Why does this code cause a compilation error?

medium

A. Interfaces cannot be instantiated.

B. LaserPrinter does not implement print() method.

C. Printer cannot be used as a variable type.

D. The print() method in LaserPrinter is not declared public.

Solution

1. Step 1: Check method visibility in implementation

   Interface methods are public by default, so implementing methods must be public.

2. Step 2: Identify method declaration in LaserPrinter

   LaserPrinter's print() method lacks the public modifier, causing a visibility mismatch error.

3. Final Answer:

   The print() method in LaserPrinter is not declared public. -> Option D

4. Quick Check:

   Interface methods require public implementation [OK]

Hint: Implement interface methods as public to avoid errors [OK]

Common Mistakes:

• Thinking interfaces can't be variable types
• Believing missing method causes error instead
• Ignoring method visibility rules

5. You are designing a payment system where multiple payment methods (CreditCard, PayPal, Crypto) can be used. To follow the principle 'Program to interface not implementation', which design is best?

hard

A. Write separate classes with no common interface and call their methods directly.

B. Create a PaymentMethod interface with a pay() method, and implement it in each payment class.

C. Use a single PaymentProcessor class with if-else to handle all payment types.

D. Make all payment classes inherit from a concrete PaymentProcessor class.

Solution

1. Step 1: Identify the need for abstraction

   Multiple payment types require a common contract to allow flexible usage.

2. Step 2: Choose design that uses interface

   Defining a PaymentMethod interface with pay() method lets each payment type implement its own logic while code depends only on the interface.

3. Final Answer:

   Create a PaymentMethod interface with a pay() method, and implement it in each payment class. -> Option B

4. Quick Check:

   Interface abstraction enables flexible, extendable design [OK]

Hint: Use interface for common behavior, implementations for details [OK]

Common Mistakes:

• Hardcoding payment types with if-else
• Not using interfaces for common behavior
• Using inheritance from concrete classes