Object-oriented design principles in LLD - Scalability & System Analysis

Scalability Analysis - Object-oriented design principles

Growth Table: Object-oriented Design Principles

Users/Scale	Design Focus	Challenges	Changes Needed
100 users	Basic OOP principles applied: encapsulation, inheritance, polymorphism	Simple class hierarchies, low complexity	Maintain clean code, follow SOLID principles
10,000 users	Increased codebase size, more modules and classes	Managing dependencies, avoiding tight coupling	Apply Dependency Injection, Interface Segregation, and design patterns
1,000,000 users	Large distributed system, multiple teams working on code	Code scalability, maintainability, and extensibility issues	Use modular design, microservices, strict adherence to Single Responsibility Principle
100,000,000 users	Massive scale, complex domain, high concurrency	Performance bottlenecks, codebase fragmentation, integration complexity	Adopt event-driven architecture, domain-driven design, and robust interface contracts

First Bottleneck

At small scale, the first bottleneck is often tight coupling between classes. This makes changes risky and slows development.

As scale grows, poor modularity and lack of clear responsibilities cause maintenance and integration problems.

At very large scale, complex interdependencies and inconsistent interfaces break the system's ability to evolve efficiently.

Scaling Solutions

• Encapsulation: Keep data and methods private to reduce impact of changes.
• Single Responsibility Principle: Each class should have one clear purpose.
• Open/Closed Principle: Design classes to be open for extension but closed for modification.
• Dependency Injection: Reduce tight coupling by injecting dependencies.
• Interface Segregation: Use small, specific interfaces to avoid forcing classes to implement unused methods.
• Modularization: Break system into modules or microservices for independent development and scaling.
• Design Patterns: Use proven patterns like Factory, Observer, Strategy to solve common problems.
• Domain-Driven Design: Model complex domains with clear boundaries and ubiquitous language.

Back-of-Envelope Cost Analysis

For a system using OOP principles:

• Codebase size grows roughly linearly with features and users.
• Maintenance cost increases if principles are not followed, causing technical debt.
• Refactoring to improve design can save 20-40% of future development time.
• Modular design reduces integration overhead, improving team productivity.
• Performance impact is minimal if design principles are followed; poor design can cause slowdowns due to unnecessary dependencies.

Interview Tip

When discussing scalability of OOP design, structure your answer as:

1. Explain the basic principles and why they matter.
2. Describe what breaks first as the system grows (tight coupling, poor modularity).
3. Suggest concrete solutions (SOLID principles, design patterns, modularization).
4. Give examples of how these solutions improve maintainability and scalability.
5. Highlight trade-offs and when to apply each principle.

Self Check

Question: Your codebase is tightly coupled and hard to maintain. The number of users grows 10x. What do you do first?

Answer: I would first refactor the code to apply the Single Responsibility Principle and Dependency Injection to reduce coupling. This makes the system easier to extend and maintain as it scales.

Key Result

Object-oriented design principles help keep code maintainable and scalable. Without them, tight coupling and poor modularity become bottlenecks as user and codebase size grow. Applying SOLID principles and modular design enables the system to scale smoothly.

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