Open/Closed Principle in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare a class that follows the Open/Closed Principle by allowing extension without modification.

LLD

class Shape {
    public void draw() {
        // base draw method
    }
}

class Circle extends Shape {
    @Override
    public void [1]() {
        System.out.println("Drawing Circle");
    }
}

Drag options to blanks, or click blank then click option'

Arender

Bpaint

Cdraw

Ddisplay

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different method name that does not override the base class method.

Modifying the base class method directly instead of overriding.

The subclass overrides the draw method to extend behavior without modifying the base class, following the Open/Closed Principle.

2fill in blank

medium

Complete the code to add a new shape class without modifying existing classes, adhering to the Open/Closed Principle.

LLD

interface Shape {
    void draw();
}

class Rectangle implements Shape {
    public void draw() {
        System.out.println("Drawing Rectangle");
    }
}

class [1] implements Shape {
    public void draw() {
        System.out.println("Drawing Triangle");
    }
}

Drag options to blanks, or click blank then click option'

ACircle

BTriangle

CSquare

DEllipse

Attempts:

3 left

💡 Hint

Common Mistakes

Modifying existing classes to add new shape logic.

Not implementing the Shape interface in the new class.

Adding a new Triangle class that implements the Shape interface extends functionality without changing existing code, following the Open/Closed Principle.

3fill in blank

hard

Fix the error in the code to ensure the Open/Closed Principle is not violated when adding new payment methods.

LLD

abstract class Payment {
    abstract void pay();
}

class CreditCardPayment extends Payment {
    void pay() {
        System.out.println("Paying with Credit Card");
    }
}

class PaymentProcessor {
    public void processPayment(Payment payment) {
        payment.[1]();
    }
}

Drag options to blanks, or click blank then click option'

Apay

Bprocess

Cexecute

DmakePayment

Attempts:

3 left

💡 Hint

Common Mistakes

Calling a method name not declared in the Payment class.

Adding conditional logic in processPayment to handle new payment types.

The processPayment method calls the abstract pay method, allowing new payment types to be added without modifying this method, thus respecting the Open/Closed Principle.

4fill in blank

hard

Fill both blanks to implement a notification system that follows the Open/Closed Principle by supporting multiple notification types.

LLD

interface Notification {
    void send();
}

class EmailNotification implements Notification {
    public void [1]() {
        System.out.println("Sending Email");
    }
}

class NotificationService {
    public void notifyUser(Notification notification) {
        notification.[2]();
    }
}

Drag options to blanks, or click blank then click option'

Asend

Bnotify

Calert

Dmessage

Attempts:

3 left

💡 Hint

Common Mistakes

Using different method names in interface and implementation.

Adding conditional logic in NotificationService for each notification type.

Both blanks use the send method to ensure the system can be extended with new notification types without modifying existing code, following the Open/Closed Principle.

5fill in blank

hard

Fill all three blanks to implement a logging system that adheres to the Open/Closed Principle by allowing new loggers without modifying existing code.

LLD

interface Logger {
    void [1](String message);
}

class ConsoleLogger implements Logger {
    public void [2](String message) {
        System.out.println("Console: " + message);
    }
}

class LoggerService {
    public void logMessage(Logger logger, String message) {
        logger.[3](message);
    }
}

Drag options to blanks, or click blank then click option'

Alog

BlogMessage

Dwrite

Attempts:

3 left

💡 Hint

Common Mistakes

Using different method names in interface and implementation.

Adding conditional logic in LoggerService for different logger types.

The method log is consistently used in the interface, implementation, and service to allow extension without modification, following the Open/Closed Principle.

Practice

1. What does the Open/Closed Principle (OCP) primarily encourage in software design?

easy

A. Software entities should be open for extension but closed for modification.

B. Software entities should be open for modification but closed for extension.

C. Software entities should be neither open nor closed for changes.

D. Software entities should always be rewritten for new features.

Solution

1. Step 1: Understand the definition of OCP

   The Open/Closed Principle states that software components should allow new functionality to be added without changing existing code.

2. Step 2: Match the principle to the options

   Software entities should be open for extension but closed for modification correctly states that entities should be open for extension (new features) but closed for modification (existing code remains unchanged).

3. Final Answer:

   Software entities should be open for extension but closed for modification. -> Option A

4. Quick Check:

   OCP = Open for extension, closed for modification [OK]

Hint: Remember: extend without changing existing code [OK]

Common Mistakes:

• Confusing 'open for extension' with 'open for modification'
• Thinking OCP means rewriting code for new features
• Ignoring the 'closed for modification' part

2. Which of the following code structures best supports the Open/Closed Principle?

easy

A. Using inheritance or interfaces to add new behavior without changing existing code.

B. Hardcoding all features inside one large class.

C. Copying and pasting code to create new features.

D. Modifying existing classes directly to add new features.

Solution

1. Step 1: Identify structures that allow extension without modification

   Inheritance and interfaces allow new classes to add behavior without changing existing classes.

2. Step 2: Evaluate options against OCP

   Using inheritance or interfaces to add new behavior without changing existing code uses inheritance/interfaces, which aligns with OCP. Other options involve modifying or duplicating code, violating OCP.

3. Final Answer:

   Using inheritance or interfaces to add new behavior without changing existing code. -> Option A

4. Quick Check:

   Inheritance/interfaces = OCP support [OK]

Hint: Choose inheritance or interfaces for extension [OK]

Common Mistakes:

• Thinking direct modification supports OCP
• Believing code duplication is acceptable
• Ignoring design patterns that enable extension

3. Consider this code snippet:

class Shape {
  area() { return 0; }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }
  area() { return this.width * this.height; }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }
  area() { return Math.PI * this.radius * this.radius; }
}

function totalArea(shapes) {
  return shapes.reduce((sum, shape) => sum + shape.area(), 0);
}

What principle does this design demonstrate?

medium

A. Liskov Substitution Principle by replacing shapes with unrelated classes.

B. Single Responsibility Principle by separating area calculation.

C. Dependency Inversion Principle by depending on concrete classes.

D. Open/Closed Principle by allowing new shapes without modifying totalArea.

Solution

1. Step 1: Analyze how new shapes are added

   New shape classes (Rectangle, Circle) extend Shape and implement area(). totalArea works without changes.

2. Step 2: Match design to OCP

   Since totalArea does not change when new shapes are added, the design follows Open/Closed Principle.

3. Final Answer:

   Open/Closed Principle by allowing new shapes without modifying totalArea. -> Option D

4. Quick Check:

   Adding shapes without changing totalArea = OCP [OK]

Hint: Look for unchanged code when adding new features [OK]

Common Mistakes:

• Confusing OCP with other SOLID principles
• Thinking totalArea must change for new shapes
• Ignoring inheritance usage

4. Given this code violates the Open/Closed Principle:

class Report {
  generate(type) {
    if (type === 'pdf') {
      // generate PDF
    } else if (type === 'html') {
      // generate HTML
    }
  }
}

What is the best fix to comply with OCP?

medium

A. Add more if-else cases inside generate() for new report types.

B. Create separate classes for each report type implementing a common interface.

C. Remove the generate() method and write report code inline.

D. Use global variables to control report type.

Solution

1. Step 1: Identify why current code violates OCP

   Adding new report types requires modifying generate() method, breaking OCP.

2. Step 2: Choose design that allows extension without modification

   Separate classes for each report type implementing a common interface allow adding new types without changing existing code.

3. Final Answer:

   Create separate classes for each report type implementing a common interface. -> Option B

4. Quick Check:

   Separate classes = extend without modify [OK]

Hint: Use separate classes, not if-else chains [OK]

Common Mistakes:

• Adding more if-else blocks inside methods
• Ignoring interface or inheritance use
• Using global variables for behavior control

5. You are designing a payment system that must support new payment methods without changing existing code. Which approach best follows the Open/Closed Principle?

hard

A. Rewrite the payment processor each time a new method is added.

B. Add new payment method code inside a large switch statement in the payment processor.

C. Implement a Payment interface and create new classes for each payment method.

D. Use global flags to select payment methods inside one class.

Solution

1. Step 1: Understand the requirement for extensibility without modification

   The system must allow adding new payment methods without changing existing code.

2. Step 2: Evaluate design options for OCP compliance

   Implementing a Payment interface and creating new classes for each method allows extension by adding classes, not modifying existing ones.

3. Final Answer:

   Implement a Payment interface and create new classes for each payment method. -> Option C

4. Quick Check:

   Interface + new classes = OCP compliance [OK]

Hint: Use interfaces and new classes for new features [OK]

Common Mistakes:

• Using switch statements that require modification
• Rewriting existing code repeatedly
• Using global flags for behavior control