Object-oriented design principles in LLD - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the Single Responsibility Principle (SRP)?

SRP means a class should have only one reason to change. It should do one job only, like a chef who only cooks and doesn't clean.

intermediate

Explain the Open/Closed Principle (OCP).

OCP says software entities should be open for extension but closed for modification. Think of a phone case that fits new phones without changing the phone itself.

intermediate

What does the Liskov Substitution Principle (LSP) ensure?

LSP means subclasses should work anywhere their parent class works without breaking things. Like replacing a car tire with a new one that fits perfectly.

advanced

Describe the Interface Segregation Principle (ISP).

ISP says clients should not depend on interfaces they do not use. It's like having separate menus for drinks and food, so you only see what you want.

advanced

What is the Dependency Inversion Principle (DIP)?

DIP means high-level modules should not depend on low-level modules. Both should depend on abstractions. Like using a universal remote that works with many devices.

Which principle states that a class should have only one reason to change?

A Open/Closed Principle

B Single Responsibility Principle

C Liskov Substitution Principle

D Dependency Inversion Principle

The Single Responsibility Principle means a class should have only one reason to change.

What does the Open/Closed Principle encourage?

A Classes should be open for modification

B Classes should be closed for extension

C Classes should be open for extension but closed for modification

D Classes should have multiple responsibilities

OCP means classes can be extended without changing existing code.

Liskov Substitution Principle ensures that:

A Subclasses can replace their parent classes without errors

B Classes should have only one responsibility

C Interfaces should be large and general

D High-level modules depend on low-level modules

LSP means subclasses should work anywhere their parent class works.

Interface Segregation Principle advises to:

A Use one big interface for all clients

B Avoid using interfaces

C Depend on concrete classes

D Split interfaces so clients only use what they need

ISP means clients should not depend on interfaces they do not use.

Dependency Inversion Principle promotes:

A Both depend on abstractions

B Low-level modules depend on high-level modules

C High-level modules depend on low-level modules

D No dependencies at all

DIP means both high and low-level modules depend on abstractions.

Explain the five main object-oriented design principles and give a simple real-life example for each.

Think about everyday objects or situations that show each principle.

How do object-oriented design principles help in building scalable and maintainable software?

Consider how good design makes life easier for developers.

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