09 LLD Design Patterns
Uploaded by
princa300609 LLD Design Patterns
Uploaded by
princa3006Low Level Design (LLD) & Design Patterns
Overview
LLD interviews test whether you can translate requirements into well-structured classes with clear
responsibilities — directly relevant to strengthening your JVM Trainee profile alongside a Spring Boot + MySQL
project.
Key Concepts
• Singleton Pattern: Ensures a class has only one instance and provides a global access point — common for
config managers, logging, or connection pools; must be made thread-safe (double-checked locking or
enum-based) in concurrent contexts.
• Factory Pattern: Delegates object creation to a factory method/class instead of using 'new' directly,
decoupling client code from concrete classes.
• Builder Pattern: Constructs complex objects step-by-step, useful when a class has many optional
parameters, avoiding telescoping constructors.
• Observer Pattern: Defines a one-to-many dependency where observers are automatically notified of state
changes in a subject — the basis of event-driven systems and React's state updates conceptually.
• Strategy Pattern: Encapsulates interchangeable algorithms behind a common interface, letting behavior be
selected/swapped at runtime without modifying the client.
• Decorator Pattern: Dynamically adds responsibilities to an object by wrapping it, as an alternative to
subclassing for extending behavior.
• Adapter Pattern: Converts the interface of a class into another interface clients expect, allowing
incompatible interfaces to work together.
• Dependency Injection: Supplying a class's dependencies from the outside (constructor/setter/framework)
rather than having it construct them itself — core to how Spring Boot manages beans.
• MVC Pattern: Separates an application into Model (data/business logic), View (presentation), and
Controller (handles input, coordinates Model and View) — the structural basis for both Spring MVC and
typical Express/React separation.
Common Interview Questions
Q1. How would you design a parking lot system?
Model core entities as classes: ParkingLot, ParkingFloor, ParkingSpot (with type: compact/large/handicap),
Vehicle (with subtypes), and a Ticket. Use a Strategy pattern for pricing, a Factory for spot allocation, and
ensure thread-safety on spot assignment/release if concurrent access is expected.
Q2. When would you use the Strategy pattern over simple if-else branching?
When the number of variants is likely to grow, when each variant has meaningfully different logic worth
isolating in its own class, or when you want to swap behavior at runtime/via configuration without
modifying existing code (Open/Closed Principle).
Q3. Explain how Dependency Injection improves testability.
Since dependencies are passed in rather than instantiated internally, tests can substitute mocks/stubs for
those dependencies, isolating the unit under test from real databases, network calls, or other side effects.
Q4. What's the difference between Factory and Builder patterns?
Factory pattern focuses on deciding which concrete class to instantiate, typically for objects that don't need
much configuration. Builder pattern focuses on constructing a single complex object step by step, especially
useful with many optional fields.
Q5. Is Singleton pattern always a good idea? What are its downsides?
It introduces global state, which can make unit testing harder (hidden dependencies, shared state across
tests) and can hide the true dependencies of a class. It also needs careful handling for thread safety in multi-
threaded applications.