Singleton Pattern: Parking Lot Application

Domain: Parking Lot Management System
In a parking lot system, certain components must exist as single coordinating instances. We will apply Singleton to ParkingLotManager, which tracks all spots and enforces capacity limits across the entire facility.
Why Singleton Here?
The parking lot has exactly one physical facility with a fixed total capacity. Multiple ParkingLotManager instances would cause inconsistent spot counts, double bookings, or capacity violations. A single manager ensures all entry gates, exit gates, and payment kiosks work with the same authoritative state.
ParkingLotManager
- instance: ParkingLotManager
- floors: List<Floor>
- availableSpots: Map<VehicleType, Integer>
- activeTickets: Map<String, Ticket>
- ParkingLotManager()
+ getInstance(): ParkingLotManager
+ parkVehicle(vehicle: Vehicle): Ticket
+ unparkVehicle(ticketId: String): Receipt
+ getAvailableCount(type: VehicleType): Integer
+ isFull(): Boolean
▼
Floor
- floorNumber: Integer
- spots: List<ParkingSpot>
+ findAvailableSpot(type: VehicleType): ParkingSpot
+ getOccupiedCount(): Integer
ParkingSpot
- spotId: String
- type: VehicleType
- isOccupied: Boolean
- vehicle: Vehicle
+ assignVehicle(vehicle: Vehicle): void
+ removeVehicle(): Vehicle
+ isAvailable(): Boolean
Interaction Flow:
First, Entry Gate calls ParkingLotManager.getInstance().parkVehicle(vehicle).

Second, Manager checks availableSpots map to see if capacity exists for the vehicle type.

Third, If available, manager iterates through floors to find an appropriate ParkingSpot via floor.findAvailableSpot(type).

Fourth, Manager assigns the vehicle to the spot, decrements availableSpots counter, creates a Ticket, stores it in activeTickets, and returns the ticket.

Fifth, Exit Gate later calls ParkingLotManager.getInstance().unparkVehicle(ticketId), which removes the vehicle, increments available count, calculates fee, and returns a Receipt.
Interview Tip: Emphasize that ParkingLotManager is the single source of truth for capacity. Multiple managers would lead to race conditions where two gates assign the same spot.
What About Multiple Parking Lots?
If your system manages multiple physical parking lots (downtown location, airport location), each lot should have its own manager instance. In this case, use a Factory Pattern or Registry Pattern to manage multiple singletons keyed by location ID, but each individual lot still has exactly one manager. The Singleton Pattern applies per parking lot, not globally across all lots.
Other Singleton Candidates in Parking Lot:
FeeCalculator: Single instance with pricing rules loaded from configuration.

DisplayBoard: If there is one central display showing available spots, it is a singleton. However, if each floor has its own display, those are separate instances (not singletons).

PaymentProcessor: May be singleton if it manages one payment gateway connection, but if supporting multiple gateways, use Strategy Pattern instead.

💡 Key Takeaways

✓ParkingLotManager is singleton because there is one physical facility to coordinate

✓Singleton ensures consistent spot availability counts across all entry/exit points

✓Manager aggregates multiple Floor objects, each containing ParkingSpot instances

✓activeTickets map tracks all currently parked vehicles in one place

✓For multi-location systems, use one singleton per parking lot facility

✓DisplayBoard and FeeCalculator are other common singleton candidates

📌 Examples

1Entry gate checking spot availability through shared manager

2Exit gate accessing same manager to process payment and release spot

3Payment kiosk querying manager for ticket details without inconsistency

← Back to Singleton Pattern Overview