# Design a Single-Station Package Locker Design the classes and core workflows for one self-service package-locker station. A delivery driver deposits a package into an available compartment of the same size, and a customer later enters a one-time access code to open that compartment. ### Required Operations - `depositPackage(size)` opens an available compartment of exactly `size` and returns a newly generated access code. It returns a clear error when no exact-size compartment is available. - `pickup(code)` validates an unexpired code and opens its compartment. A successful pickup frees the compartment and consumes the code. - `openExpiredCompartments()` opens compartments whose codes have expired so staff can remove and return those packages. - `confirmExpiredPackageRemoved(compartment_id)` records that staff physically removed an expired package, consumes its expired code, and returns the compartment to service. This confirmation method is an explicit practice completion step; the linked walkthrough mentions such a separate cleanup method but leaves it outside its core pseudocode. ### Constraints & Assumptions - The only sizes are small, medium, and large. - Size matching is exact. A small package cannot use a medium or large compartment in this exercise. - Each package receives its own code and occupies its own compartment. - A code expires exactly seven days after deposit. - An expired package remains physically in its compartment; expiry alone must not make that compartment available. - The system only validates a wrong code and returns an error. Failed-attempt counters and lockout are out of scope. - Deposit reservations, delivery routing, notifications, multiple locker stations, UI, and payment are out of scope. - `openExpiredCompartments()` does not free anything. Until staff confirmation, repeated calls return the same expired occupied compartment IDs in ascending ID order and idempotently request those doors to open. - `confirmExpiredPackageRemoved` returns `true` exactly once for a compartment occupied by an expired-token package awaiting removal. It returns `false` and changes nothing for an unknown compartment, a free compartment, a non-expired package, or a repeated confirmation. ### Clarifying Questions to Ask - Is exact-size matching required, or may a larger compartment be used? For this contract, matching is exact. - Does the locker return the code or deliver it by SMS/email? It returns the code; delivery is handled elsewhere. - What happens after expiry? Staff opens expired compartments and physically handles the packages. - Should a used code be distinguishable from a code that never existed? - Does the hardware report that a door opened or closed, or may we model `open()` as a successful command? ### What a Strong Answer Covers - Focused `Locker`, `Compartment`, and `AccessToken` responsibilities. - Occupancy modeled independently from token validity. - Exact-size allocation and a defensible availability data structure. - Deposit, pickup, expiry, and staff-handling state transitions. - A separate, atomic staff confirmation that removes the expired token, frees the compartment, and restores any exact-size availability index. - Unique code generation, seven-day expiry checks, and clear invalid/expired errors. - Tests for no capacity, reused codes, boundary-time expiry, and expired packages that still occupy space. ### Follow-up Questions - When is a linear scan simpler than an availability queue per size? - What state must change atomically during a successful pickup? - Why is it incorrect to infer physical occupancy only from whether a token is currently valid? - How would you extend the design later for larger-size fallback or sensor-confirmed deposits?