Parking strategy pattern in LLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the role of the strategy pattern in parking systems

In a parking system using the strategy pattern, what is the main purpose of the 'strategy' interface?

A To manage the physical layout of the parking lot

B To store all parked vehicles in a single list

C To handle payment processing for parking fees

D To define a common interface for different parking algorithms so they can be swapped easily

💡 Hint

Think about how different parking methods can be used interchangeably.

The strategy pattern defines a common interface for various parking algorithms, allowing the system to switch between them without changing the client code.

❓ Architecture

intermediate

Choosing the right components for a parking strategy pattern

Which components are essential in implementing a parking system using the strategy pattern?

A Context, Strategy interface, Concrete Strategies

B Database, User Interface, Payment Gateway

C Vehicle class, Ticket class, Security module

D Sensor hardware, Camera system, Gate controller

💡 Hint

Focus on software design components related to the strategy pattern.

The strategy pattern requires a context that uses a strategy interface, which is implemented by concrete strategy classes representing different parking algorithms.

❓ scaling

advanced

Scaling a parking system with multiple parking strategies

When scaling a parking system that supports multiple parking strategies, which approach best ensures maintainability and performance?

A Create separate parking systems for each strategy without sharing code

B Hardcode all parking strategies in a single class to reduce overhead

C Use the strategy pattern with dependency injection to select strategies dynamically and cache frequent decisions

D Use a monolithic design where all strategies run in parallel regardless of need

💡 Hint

Think about flexibility and avoiding code duplication while keeping performance.

Dependency injection allows dynamic selection of strategies, and caching helps improve performance by avoiding repeated calculations.

❓ tradeoff

advanced

Tradeoffs in choosing parking strategies

What is a key tradeoff when selecting a parking strategy that prioritizes minimal walking distance over maximizing space usage?

A Higher parking capacity but increased walking distance for users

B Improved user convenience but potentially lower parking capacity

C Reduced system complexity but slower parking allocation

D Increased hardware costs but simpler software design

💡 Hint

Consider what happens when you focus on user convenience versus space efficiency.

Prioritizing minimal walking distance improves user experience but may leave some spaces unused, reducing overall capacity.

❓ component

expert

Request flow in a parking system using the strategy pattern

Given a parking system where the context delegates parking spot allocation to a strategy, what is the correct sequence of steps when a vehicle arrives?

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,2,1,4

💡 Hint

Think about the natural order of request handling and delegation.

The vehicle first requests a spot, the context receives and delegates to the strategy, which selects the spot, then the context returns it.

Practice

1. What is the main purpose of using the Parking Strategy Pattern in a parking lot system?

easy

A. To store vehicle details in a database

B. To manage payment processing for parking fees

C. To allow different algorithms for finding parking spots without changing the main system

D. To control the physical gates of the parking lot

Solution

1. Step 1: Understand the role of strategy pattern

   The strategy pattern lets you swap different algorithms easily without changing the main code.

2. Step 2: Apply this to parking system context

   In parking, it means you can change how spots are found without rewriting the whole system.

3. Final Answer:

   To allow different algorithms for finding parking spots without changing the main system -> Option C

4. Quick Check:

   Strategy pattern = flexible parking spot finding [OK]

Hint: Strategy pattern = flexible algorithm swapping [OK]

Common Mistakes:

• Confusing strategy pattern with data storage
• Thinking it controls hardware like gates
• Mixing it with payment processing logic

2. Which of the following is the correct way to define a parking strategy interface in a typical object-oriented design?

easy

A. class ParkingStrategy { findSpot(vehicle) {} }

B. function findSpot(vehicle) { return spot; }

C. var ParkingStrategy = new Object();

D. interface ParkingStrategy { findSpot(vehicle): Spot; }

Solution

1. Step 1: Identify interface syntax in OOP

   Interfaces define method signatures without implementation, e.g., interface ParkingStrategy { findSpot(vehicle): Spot; }.

2. Step 2: Compare options

   interface ParkingStrategy { findSpot(vehicle): Spot; } correctly uses interface with method signature. Others are class, function, or object, not interface.

3. Final Answer:

   interface ParkingStrategy { findSpot(vehicle): Spot; } -> Option D

4. Quick Check:

   Interface = method signature only [OK]

Hint: Interface defines method signatures only [OK]

Common Mistakes:

• Using class instead of interface for strategy
• Defining functions outside interface context
• Confusing object creation with interface definition

3. Given the following code snippet for two parking strategies, what will be the output when findSpot(vehicle) is called using NearestParkingStrategy?

class NearestParkingStrategy {
  findSpot(vehicle) {
    return "Nearest spot found";
  }
}
class RandomParkingStrategy {
  findSpot(vehicle) {
    return "Random spot found";
  }
}
const strategy = new NearestParkingStrategy();
console.log(strategy.findSpot('car'));

medium

A. "Nearest spot found"

B. "Random spot found"

C. undefined

D. Error: findSpot not defined

Solution

1. Step 1: Identify which strategy instance is used

   The code creates an instance of NearestParkingStrategy and calls findSpot.

2. Step 2: Check method output for that class

   NearestParkingStrategy.findSpot returns "Nearest spot found".

3. Final Answer:

   "Nearest spot found" -> Option A

4. Quick Check:

   Instance method output = "Nearest spot found" [OK]

Hint: Instance method output matches class used [OK]

Common Mistakes:

• Confusing which strategy instance is created
• Assuming random strategy is used
• Expecting undefined or error without reason

4. In the following code, what is the main issue that prevents the ParkingLot from using different parking strategies correctly?

class ParkingLot {
  constructor() {
    this.strategy = null;
  }
  setStrategy(strategy) {
    this.strategy = strategy;
  }
  park(vehicle) {
    return this.strategy.findSpot(vehicle);
  }
}
const lot = new ParkingLot();
lot.park('car');

medium

A. No strategy is set before calling park, causing an error

B. The park method should not call findSpot

C. The strategy property should be a list, not a single object

D. The constructor should initialize strategy with a default value

Solution

1. Step 1: Analyze object initialization and method calls

   The ParkingLot is created with strategy = null. No strategy is set before calling park.

2. Step 2: Understand consequence of null strategy

   Calling this.strategy.findSpot(vehicle) when strategy is null causes an error.

3. Final Answer:

   No strategy is set before calling park, causing an error -> Option A

4. Quick Check:

   Null strategy causes error on method call [OK]

Hint: Always set strategy before use [OK]

Common Mistakes:

• Thinking park method logic is wrong
• Assuming strategy should be a list
• Ignoring null initialization problem

5. You want to design a parking system that supports multiple vehicle types (car, bike, truck) and different parking strategies (nearest, random, reserved). Which design approach best uses the Parking Strategy Pattern to handle this complexity?

hard

A. Create separate parking lot classes for each vehicle type and hardcode the strategy inside each

B. Use a single ParkingLot class with a strategy interface; implement different strategies and select based on vehicle type at runtime

C. Store all vehicles in one list and assign spots randomly without strategy pattern

D. Use global variables to track vehicle types and apply strategies in procedural code

Solution

1. Step 1: Identify need for flexibility and scalability

   Supporting multiple vehicle types and strategies requires flexible design without code duplication.

2. Step 2: Apply strategy pattern with runtime selection

   Using one ParkingLot class with strategy interface allows swapping strategies dynamically based on vehicle type.

3. Step 3: Evaluate other options

   Create separate parking lot classes for each vehicle type and hardcode the strategy inside each duplicates code, C ignores strategy pattern, D uses poor global state management.

4. Final Answer:

   Use a single ParkingLot class with a strategy interface; implement different strategies and select based on vehicle type at runtime -> Option B

5. Quick Check:

   Strategy pattern + runtime selection = best design [OK]

Hint: Use one class + strategy interface + runtime choice [OK]

Common Mistakes:

• Duplicating classes per vehicle type
• Ignoring strategy pattern benefits
• Using global variables instead of OOP