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.

Practice

1. Which of the following best describes the Single Responsibility Principle (SRP) in object-oriented design?

easy

A. Classes should be tightly coupled to improve performance.

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

C. Objects should be able to change their behavior at runtime.

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

Solution

1. Step 1: Understand SRP definition

   The Single Responsibility Principle states that a class should have only one reason to change, meaning it should focus on a single job or responsibility.

2. Step 2: Evaluate options against SRP

   A class should have only one reason to change, meaning it should have only one job. matches this definition exactly. Options A, B, and C describe other concepts or incorrect ideas.

3. Final Answer:

   A class should have only one reason to change, meaning it should have only one job. -> Option D

4. Quick Check:

   Single Responsibility Principle = One class, one job [OK]

Hint: SRP means one class, one responsibility [OK]

Common Mistakes:

• Confusing SRP with inheritance rules
• Thinking SRP allows multiple unrelated jobs in one class
• Believing tight coupling is good design

2. Which syntax correctly demonstrates the Open/Closed Principle in class design?

easy

A. class Shape { void draw() {} } class Circle { void draw() { /* draw circle */ } }

B. class Shape { void draw() {} } class Circle extends Shape { void draw() { /* draw circle */ } }

C. class Shape { void draw() {} } class Circle extends Shape { void draw() { super.draw(); } }

D. class Shape { void draw() {} } class Circle extends Shape { void draw() { /* draw circle */ } } class Square extends Circle {}

Solution

1. Step 1: Understand Open/Closed Principle (OCP)

   OCP means software entities like classes should be open for extension but closed for modification. This means you can add new behavior by extending classes without changing existing code.

2. Step 2: Analyze options for OCP compliance

   class Shape { void draw() {} } class Circle extends Shape { void draw() { /* draw circle */ } } shows a base class Shape and a subclass Circle that extends Shape and overrides draw(), adding new behavior without modifying Shape. This follows OCP. class Shape { void draw() {} } class Circle { void draw() { /* draw circle */ } } lacks inheritance, so no extension. class Shape { void draw() {} } class Circle extends Shape { void draw() { super.draw(); } } calls super.draw() but does not add new behavior. class Shape { void draw() {} } class Circle extends Shape { void draw() { /* draw circle */ } } class Square extends Circle {} extends Circle with Square, which is allowed but less clear and may break OCP if Square changes Circle behavior.

3. Final Answer:

   class Shape { void draw() {} } class Circle extends Shape { void draw() { /* draw circle */ } } -> Option B

4. Quick Check:

   Open/Closed = Extend by subclassing, no base change [OK]

Hint: OCP means extend classes, don't modify them [OK]

Common Mistakes:

• Ignoring inheritance for extension
• Modifying base class instead of extending
• Confusing method overriding with no added behavior

3. Consider the following Python code snippet applying the Liskov Substitution Principle (LSP):

class Bird:
    def fly(self):
        return "Flying"

class Penguin(Bird):
    def fly(self):
        return "Cannot fly"

bird = Bird()
penguin = Penguin()
print(bird.fly())
print(penguin.fly())

What is the output of this code?

medium

A. "Flying" followed by "Cannot fly"

B. Both print "Flying"

C. Runtime error because Penguin cannot fly

D. Both print "Cannot fly"

Solution

1. Step 1: Understand code behavior

   Bird class has fly() returning "Flying". Penguin inherits Bird but overrides fly() to return "Cannot fly". bird.fly() prints "Flying". penguin.fly() prints "Cannot fly".

2. Step 2: Predict output lines

   First print outputs "Flying". Second print outputs "Cannot fly" as per Penguin's override.

3. Final Answer:

   "Flying" followed by "Cannot fly" -> Option A

4. Quick Check:

   Subclass override changes output correctly [OK]

Hint: Subclass method overrides parent method output [OK]

Common Mistakes:

• Assuming subclass must behave exactly like parent
• Expecting runtime error for overridden method
• Confusing method override with inheritance

4. Identify the problem in the following Java code violating the Dependency Inversion Principle (DIP):

class LightBulb {
    void turnOn() { System.out.println("Light on"); }
    void turnOff() { System.out.println("Light off"); }
}

class Switch {
    private LightBulb bulb = new LightBulb();
    void operate(boolean on) {
        if(on) bulb.turnOn();
        else bulb.turnOff();
    }
}

medium

A. Switch class should create multiple LightBulb instances.

B. LightBulb class should not have turnOn and turnOff methods.

C. Switch class directly depends on concrete LightBulb class instead of an abstraction.

D. Switch class should inherit from LightBulb.

Solution

1. Step 1: Understand Dependency Inversion Principle (DIP)

   DIP states that high-level modules should not depend on low-level modules directly; both should depend on abstractions (interfaces or abstract classes).

2. Step 2: Analyze code for DIP violation

   Switch class creates and uses a concrete LightBulb instance directly, tightly coupling Switch to LightBulb. This violates DIP because Switch depends on a concrete class, not an abstraction.

3. Final Answer:

   Switch class directly depends on concrete LightBulb class instead of an abstraction. -> Option C

4. Quick Check:

   DIP = Depend on abstractions, not concrete classes [OK]

Hint: High-level classes should depend on interfaces, not concrete classes [OK]

Common Mistakes:

• Thinking methods in LightBulb are wrong
• Believing multiple instances are needed
• Confusing inheritance with dependency

5. You are designing a payment system that must support multiple payment methods (credit card, PayPal, crypto). Which object-oriented design principle helps you add new payment methods without changing existing code, and how should you apply it?

hard

A. Use the Open/Closed Principle by defining a Payment interface and implementing new payment classes for each method.

B. Use the Single Responsibility Principle by putting all payment logic in one PaymentProcessor class.

C. Use the Liskov Substitution Principle by making all payment classes inherit from a base Payment class but override methods differently.

D. Use the Dependency Inversion Principle by making payment classes depend on concrete implementations.

Solution

1. Step 1: Identify the need for extensibility

   The system must allow adding new payment methods without modifying existing code, which is a classic use case for the Open/Closed Principle (OCP).

2. Step 2: Apply OCP with interface and implementations

   Define a Payment interface with common methods. Implement each payment method (credit card, PayPal, crypto) as separate classes implementing this interface. This allows adding new methods by creating new classes without changing existing ones.

3. Final Answer:

   Use the Open/Closed Principle by defining a Payment interface and implementing new payment classes for each method. -> Option A

4. Quick Check:

   OCP = Add new classes, no existing code change [OK]

Hint: OCP means add new classes, don't modify old ones [OK]

Common Mistakes:

• Putting all logic in one class violating SRP
• Confusing inheritance with extensibility
• Depending on concrete classes instead of abstractions