How would you extend the parking lot design for multiple locations?

Direct Answer

Introduce a ParkingLotNetwork or ParkingManagementSystem class that aggregates multiple ParkingLot instances. Each ParkingLot remains an independent unit with its own floors and spots. The network layer provides cross-location operations like findNearestAvailableSpot(Location userLocation) or getTotalOccupancyAcrossAllLots().

Deep Dive & Architecture

Each location remains its own aggregate

A ParkingLot continues to own its floors, spots, tickets, and local allocation rules. A ParkingNetwork keeps a map of lot ids to lots and handles operations that cross location boundaries. This avoids coupling every lot to every other lot.

The network coordinates a concrete lookup

For example, if lots A, B, and C report availability, findNearestAvailable(userLocation, CAR) filters out lots without a car spot, calculates distance for the remaining lots, and returns the closest candidate. The chosen lot must still reserve the spot; a network-level availability count is only a snapshot and cannot guarantee the spot remains free.

Distribution changes the freshness boundary

In one process, the network may call lot objects directly. With remote locations, each lot can publish occupancy updates and expose a reservation API. The network may serve slightly stale search results, but the location is the final authority for a claim. That separation lets search scale independently without weakening the no-double-booking rule inside each lot.

Code Example

record GeoLocation(double lat, double lng) {}

interface IParkingLot {                       // shared contract (Composite)
    Optional<ParkingTicket> park(Vehicle v);
    int availableCount();
}

class ParkingLot implements IParkingLot { /* unchanged single-lot logic */ }

class ParkingLotNetwork implements IParkingLot {
    private final Map<String, ParkingLot> lots = new HashMap<>();

    // Cross-location operation the single lot never needed
    Optional<ParkingLot> nearestWithSpace(GeoLocation user, SpotSize size) {
        return lots.values().stream()
            .filter(l -> l.availableCount() > 0)
            .min(Comparator.comparingDouble(l -> distance(user, l.location())));
    }
    public Optional<ParkingTicket> park(Vehicle v) {            // delegate to a lot
        return lots.values().stream().map(l -> l.park(v))
                   .filter(Optional::isPresent).map(Optional::get).findFirst();
    }
    public int availableCount() {
        return lots.values().stream().mapToInt(ParkingLot::availableCount).sum();
    }
}

ParkingLot is untouched — the network only aggregates and delegates.

Common Mistakes & Pitfalls

• Adding a neighbors list to ParkingLot — creates circular references and makes each lot know about others. Coordination belongs in the network layer.
• Duplicating spot-search logic in the network — it should delegate to each lot, not re-implement parking (DRY).
• No lot identity — each lot needs an id and GeoLocation, or you can't route or report per-lot.
• Modifying ParkingLot at all — if you're editing it, you've missed the Open/Closed point.