Design a Parking Lot - LLD with OOP (Classes, Patterns, Extensibility)

🎯

Design a Parking Lot - LLD with OOP (Classes, Patterns, Extensibility)

hardOOPAmazonGoogleMicrosoft

Imagine you are tasked with designing the software for a multi-level parking lot that can handle different vehicle types, dynamic pricing, and future feature additions without major rewrites.

💡 Beginners often confuse design problems like this with algorithmic puzzles and miss the importance of extensibility and design patterns in managing complexity.

📋

Interview Question

Explain how you would design a parking lot system using object-oriented principles, focusing on class design, design patterns, and extensibility for future requirements.

Object-oriented design principles (encapsulation, abstraction, inheritance, polymorphism)Design patterns relevant to LLD (Factory, Strategy, Singleton)Extensibility and maintainability in system design

💡

Scenario & Trace

ScenarioA parking lot supports multiple vehicle types (car, bike, truck) and different spot sizes.

Vehicle objects are created with type info → ParkingSpot objects are categorized by size → ParkingLot manages allocation by matching vehicle type to spot size → Factory pattern creates vehicle and spot instances → Strategy pattern handles different pricing models per vehicle type.

ScenarioThe parking lot needs to add a new feature for monthly subscriptions without changing existing code.

Subscription pricing strategy is added as a new class implementing the pricing interface → ParkingLot uses the Strategy pattern to switch pricing dynamically → Existing classes remain unchanged, demonstrating extensibility.

• What if all parking spots are full but a vehicle arrives?
• How to handle different vehicle sizes that don’t fit standard spots?
• What happens when multiple vehicles arrive simultaneously for the last available spot?

⚠️

Common Mistakes

Treating the problem as just an algorithmic puzzle rather than a design problem

Interviewer perceives lack of system design thinking and OOP understanding

✅ Focus on class design, relationships, and extensibility rather than just parking allocation logic

Ignoring extensibility and hardcoding vehicle types or pricing logic

Design becomes rigid and unmaintainable, interviewer doubts scalability

✅ Use design patterns like Factory and Strategy to allow easy addition of new types and policies

Not considering concurrency or edge cases like full capacity or simultaneous requests

Design appears naive and incomplete, raising red flags about real-world readiness

✅ Discuss synchronization, locking, or queuing mechanisms and how the system handles no available spots

Confusing inheritance with composition and overusing inheritance

Design becomes inflexible and tightly coupled, making future changes difficult

✅ Favor composition and programming to interfaces to enhance flexibility

🧠

Basic Definition - What It Is

💡 This level covers the fundamental understanding of what a parking lot design entails in OOP terms.

Intuition

Designing a parking lot system means modeling real-world entities as classes and defining their relationships.

Explanation

At the basic level, designing a parking lot involves identifying key entities such as Vehicle, ParkingSpot, and ParkingLot. Each entity is represented as a class with attributes and behaviors. For example, a Vehicle class might have properties like vehicle type and license number, while ParkingSpot has size and availability status. The ParkingLot class manages the collection of spots and handles parking and unparking operations. This level focuses on clear class definitions and simple interactions without deep pattern usage or extensibility considerations.

Memory Hook

💡 Think of the parking lot as a set of boxes (spots) and items (vehicles) that fit into them.

Interview Questions

❓ What classes would you create for a parking lot system?

• Vehicle class with type and license
• ParkingSpot class with size and availability
• ParkingLot class managing spots and vehicles

⏱

Depth Level

Interview Time30 seconds

Depthbasic

Covers fundamental class identification and relationships; sufficient for quick screening.

Interview Target: Minimum floor - never go below this

Knowing only this will help you pass initial screening but won’t impress in detailed design rounds.

🧠

Mechanism Depth - How It Works

💡 This level explains the internal design mechanisms, patterns, and extensibility strategies expected in product company interviews.

Intuition

A robust parking lot design uses design patterns and OOP principles to handle complexity and future changes gracefully.

Explanation

At this level, you explain how design patterns like Factory are used to instantiate different vehicle and parking spot types, enabling easy addition of new types without modifying existing code. The Strategy pattern allows dynamic pricing models or parking policies to be swapped without changing core logic. Singleton pattern ensures a single instance of ParkingLot manages the entire system state. You also discuss how inheritance and interfaces abstract common behaviors (e.g., Vehicle interface with Car, Bike subclasses). Extensibility is achieved by programming to interfaces and using composition over inheritance where appropriate. Concurrency considerations for simultaneous parking requests and handling edge cases like full capacity are also addressed.

Memory Hook

💡 Design patterns are the toolkit that lets your parking lot grow and adapt like a well-oiled machine.

Interview Questions

❓ How would you add a new vehicle type or pricing strategy without changing existing classes?

• Use Factory pattern to create new vehicle and spot types
• Implement new pricing strategy class following Strategy interface
• ParkingLot uses interfaces and composition to remain unchanged

❓ How do you ensure only one ParkingLot instance manages the system?

• Implement Singleton pattern for ParkingLot
• Provide global access point while preventing multiple instances

⏱

Depth Level

Interview Time2-3 minutes

Depthintermediate

Demonstrates understanding of design patterns, OOP principles, and extensibility; expected in FAANG on-sites.

Interview Target: Target level for FAANG on-sites

Mastering this level distinguishes you from most candidates and shows readiness for complex system design.

📊

Explanation Depth Levels

💡 Choose your explanation depth based on the interview stage and company expectations.

Level	Interview Time	Suitable For	Risk
Basic Definition	30s	Screening call or initial rounds	Too shallow for on-site or design-focused interviews
Mechanism Depth	2-3 minutes	On-site interviews at FAANG and top product companies	Requires strong understanding; missing this level reduces chances of success

💼

Interview Strategy

💡 Use this guide to structure your explanation clearly and confidently before every mock or real interview.

How to Present

Start with a clear definition of the problem and key classes involvedGive a relatable example or analogy to ground your explanationExplain the internal design using relevant design patterns and OOP principlesDiscuss edge cases and how your design handles them

Time Allocation

Definition: 30s → Example: 1min → Mechanism: 2min → Edge cases: 30s. Total ~4min

What the Interviewer Tests

Interviewer checks your ability to model real-world entities, apply design patterns, ensure extensibility, and handle edge cases.

Common Follow-ups

• How would you handle concurrency when multiple vehicles arrive simultaneously?
• What changes if the parking lot supports monthly subscriptions or dynamic pricing?

💡 These follow-ups test your depth in concurrency and adaptability of your design.

🔍

Pattern Recognition

When to Use

When asked to design a real-world system with multiple interacting entities and future extensibility requirements.

Signature Phrases

'Explain how you would design...''Compare different design approaches for...''What happens when you add a new feature to...'

NOT This Pattern When

Similar Problems

Practice

1. You need to add multiple optional features to a core object dynamically at runtime without creating a subclass for every possible combination. Which design approach best supports this requirement?

easy

A. Apply memoization to cache feature combinations for reuse

B. Create a large inheritance hierarchy with subclasses for each feature combination

C. Use a greedy algorithm to select features based on priority

D. Use composition to wrap the core object with feature objects that add behavior dynamically

Solution

1. Step 1: Understand the problem constraints

   The problem requires adding features dynamically without subclass explosion.

2. Step 2: Identify the design pattern that supports dynamic behavior wrapping

   The Decorator Pattern uses composition to wrap objects and add behavior at runtime, avoiding subclassing for every combination.

3. Final Answer:

   Option D -> Option D

4. Quick Check:

   Dynamic wrapping via composition avoids subclass explosion [OK]

Hint: Dynamic wrapping avoids subclass explosion [OK]

Common Mistakes:

• Thinking subclassing is the only way to add features
• Confusing greedy algorithms with design patterns

2. Trace the sequence of events when a user attempts to borrow a book that is currently checked out by another user in a concurrent environment. Which step correctly describes the system's behavior?

easy

A. The Library class queues the request and processes it after the current loan expires without immediate feedback

B. The system immediately updates the book status to 'borrowed' for the requesting user without checking current loans

C. The User class updates its borrowed books list first, then the system verifies availability asynchronously

D. The LoanManager checks the book's availability, detects it is loaned out, and denies the request atomically

Solution

1. Step 1: Check availability atomically

   LoanManager must verify the book is available before granting loan to prevent race conditions.

2. Step 2: Why not immediate update?

   The system immediately updates the book status to 'borrowed' for the requesting user without checking current loans risks data inconsistency by ignoring current loan state.

3. Step 3: Why not User updates first?

   The User class updates its borrowed books list first, then the system verifies availability asynchronously breaks transactional integrity and can cause stale or conflicting states.

4. Step 4: Why not queue without feedback?

   The Library class queues the request and processes it after the current loan expires without immediate feedback delays user feedback and complicates user experience; immediate denial is standard.

5. Final Answer:

   Option D -> Option D

6. Quick Check:

   Atomic availability check and denial maintain consistency and user clarity.

Hint: Always verify resource availability atomically before state changes in concurrency [OK]

Common Mistakes:

• Assuming immediate state update without checks
• Updating user state before system validation
• Delaying feedback by queuing without immediate response

3. What is the time complexity of computing the cost() method when stacking k decorators on a core object using the Decorator Pattern with dynamic behavior injection?

medium

A. O(1) because each decorator adds a fixed cost

B. O(k) because each decorator delegates the call to the next one

C. O(k^2) because each decorator calls all previous decorators recursively

D. O(log k) because decorators form a balanced tree structure

Solution

1. Step 1: Identify call chain length

   Each decorator's cost() calls the wrapped object's cost(), forming a chain of length k.

2. Step 2: Calculate total calls

   Cost computation requires traversing all k decorators once, so time complexity is O(k).

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   Each decorator adds constant work, total linear in k [OK]

Hint: Decorator calls chain length equals number of decorators [OK]

Common Mistakes:

• Assuming O(1) because cost is a simple addition
• Mistaking recursive calls as quadratic

4. What is a common trade-off or limitation when strictly enforcing the Liskov Substitution Principle in a large inheritance hierarchy?

medium

A. It can lead to overly rigid designs that prevent useful specialization.

B. It always improves code flexibility and reduces bugs without downsides.

C. It allows subclasses to freely change method signatures for optimization.

D. It eliminates the need for interface segregation.

Solution

1. Step 1: Understand strict LSP enforcement

   Strict LSP means subclasses cannot alter behavior or method contracts in incompatible ways.

2. Step 2: Analyze trade-offs

   This can restrict subclass implementations, making designs rigid and limiting specialization.

3. Step 3: Evaluate options

   It can lead to overly rigid designs that prevent useful specialization. correctly identifies rigidity as a trade-off. It always improves code flexibility and reduces bugs without downsides. is false; strict LSP can reduce flexibility. It allows subclasses to freely change method signatures for optimization. is incorrect; method signatures must respect variance rules. It eliminates the need for interface segregation. is false; interface segregation addresses different concerns.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Strict LSP can constrain subclass design choices.

Hint: Strict LSP enforces substitutability but can limit subclass flexibility.

Common Mistakes:

• Believing strict LSP has no downsides
• Confusing LSP with interface segregation
• Assuming method signatures can be freely changed

5. Which of the following statements about the Open/Closed Principle is INCORRECT?

medium

A. OCP means you should never modify existing code once it's written

B. OCP encourages designing modules that can be extended without changing their source code

C. Abstraction and polymorphism are key enablers of OCP

D. OCP helps reduce bugs by minimizing changes to tested code

Solution

1. Step 1: Analyze statement A

   OCP does not forbid all modifications; it encourages minimizing changes to stable, tested code but allows modifications when necessary.

2. Step 2: Validate other statements

   Statements B, C, and D correctly describe OCP's goals and mechanisms.

3. Step 3: Why A is incorrect

   Absolute prohibition of modification is impractical; OCP is about minimizing and isolating changes.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   OCP is about minimizing, not forbidding, modifications.

Hint: OCP minimizes, but does not forbid, code changes [OK]

Common Mistakes:

• Interpreting OCP as no code changes ever allowed
• Ignoring the role of abstraction in OCP
• Underestimating OCP's impact on bug reduction