Object-oriented design principles in LLD - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a class with a constructor in object-oriented design.

LLD

class Car:
    def __init__(self, make, model):
        self.make = make
        self.model = [1]

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

Aself

Bmodel

Cmake

DCar

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'make' instead of 'model' for the model attribute.

Using 'self' or class name on the right side incorrectly.

The constructor assigns the parameter model to the instance variable self.model. So, model is the correct value.

2fill in blank

medium

Complete the code to implement inheritance where class Dog inherits from class Animal.

LLD

class Animal:
    def speak(self):
        pass

class Dog([1]):
    def speak(self):
        return "Woof!"

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

ADog

BSpeak

Cobject

DAnimal

Attempts:

3 left

💡 Hint

Common Mistakes

Using the child class name as the parent class.

Using unrelated class names.

In inheritance, the child class Dog inherits from the parent class Animal. So, Animal is the correct class to inherit from.

3fill in blank

hard

Fix the error in the code to correctly override a method in subclass.

LLD

class Vehicle:
    def start(self):
        return "Vehicle started"

class Bike(Vehicle):
    def start(self):
        return [1]

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

Astart()

BVehicle.start()

Csuper().start() + " and Bike ready"

Dself.start()

Attempts:

3 left

💡 Hint

Common Mistakes

Calling the method without super() causing recursion.

Calling the method on the class without instance.

To override and extend the parent method, use super().start() to call the parent method, then add the subclass behavior.

4fill in blank

hard

Fill both blanks to implement encapsulation by making attributes private and providing getter method.

LLD

class Person:
    def __init__(self, name):
        self.[1]name = name
    
    def get_name(self):
        return self.[2]name

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

A__

B_

Cself.

Dpublic_

Attempts:

3 left

💡 Hint

Common Mistakes

Using single underscore which is only a convention, not enforced privacy.

Using 'self.' prefix inside the attribute name.

In Python, prefixing attribute names with double underscores __ makes them private (name mangling). The getter accesses the same private attribute.

5fill in blank

hard

Fill all three blanks to implement polymorphism with two classes having the same method name but different behavior.

LLD

class Cat:
    def sound(self):
        return [1]

class Cow:
    def sound(self):
        return [2]

animals = [Cat(), Cow()]
results = [animal.[3]() for animal in animals]

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

A"Meow"

B"Moo"

Csound

Dspeak

Attempts:

3 left

💡 Hint

Common Mistakes

Using different method names causing attribute errors.

Returning incorrect strings for animal sounds.

Polymorphism allows different classes to have methods with the same name. Here, both Cat and Cow have sound method. The list comprehension calls sound() on each object.

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