case study · 18 MIN READ

Parking Lot

Model parking as controlled state transitions over independently identifiable vehicles and spaces. Allocation policy decides compatibility; the lot protects occupancy and ticket uniqueness.

Reading completion is independent of quizzes and challenges.

What you’ll understand

Model parking as controlled state transitions over independently identifiable vehicles and spaces. Allocation policy decides compatibility; the lot protects occupancy and ticket uniqueness.
ParkingLot owns occupancy; park validates identity and capacity before allocation, while leave releases exactly the matching occupied space.
Evaluate the tradeoff: This model uses exact-kind matching and a deterministic first-fit policy. A real lot may support bike-in-car fallback, pricing, reservations, and persistence; each is a separate policy or capability.

Useful first: Classes and Objects

The idea and when to recognize it

Model parking as controlled state transitions over independently identifiable vehicles and spaces. Allocation policy decides compatibility; the lot protects occupancy and ticket uniqueness.

Requirement: A lot has bike and car spaces. It must park a vehicle in the first available space of the same kind and release that vehicle later.
Change to anticipate: Reject incompatible allocation, full capacity, and duplicate active parking sessions without modifying occupied spaces.
Design goal: ParkingLot owns occupancy; park validates identity and capacity before allocation, while leave releases exactly the matching occupied space.

Start with the concrete problem

A lot has bike and car spaces. It must park a vehicle in the first available space of the same kind and release that vehicle later.

Reject incompatible allocation, full capacity, and duplicate active parking sessions without modifying occupied spaces.

Direct implementation	Revised design
Allocating without checking existing occupancy or vehicle identity can issue two active spaces to the same vehicle or overwrite another customer.	ParkingLot owns occupancy; park validates identity and capacity before allocation, while leave releases exactly the matching occupied space.
The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design.	This model uses exact-kind matching and a deterministic first-fit policy. A real lot may support bike-in-car fallback, pricing, reservations, and persistence; each is a separate policy or capability.

Scope and extension questions

This is a deterministic single-process model. Persistence, authentication, real network calls, and distributed coordination are outside this exercise.

Which public operation must be atomic if two callers act at once?
What data must be saved to recover after a restart?
How would you change one policy without rewriting the core state transitions?

Responsibilities and contracts

ParkingLot owns occupancy; park validates identity and capacity before allocation, while leave releases exactly the matching occupied space.

ParkingLot: Protects occupancy invariants. Public operations: park(id,kind), leave(id)
Space: Stores kind and occupant. Public operations: kind, vehicle
Vehicle: Has stable identity and kind. Public operations: id, kind

Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.

class diagramSelect a participant below

ParkingLot

Protects occupancy invariants

park(id,kind) · leave(id)

Relationships and notation

ParkingLot → Space: owns spaces. Composition ◆ owned lifecycle
Space → Vehicle: temporarily occupied by. Association · knows another object

Preparing the design walkthrough…

Follow the interaction

Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.

GUIDED SIMULATIONExample language

Scenario Implementation

A release makes the occupied space available again.

A finite, authored walkthrough of this fixture. Source code is verified in tests; it is not executed by this page.

class diagramSelect a participant below

ParkingLot

Protects occupancy invariants

park(id,kind) · leave(id)

Relationships and notation

ParkingLot → Space: owns spaces. Composition ◆ owned lifecycle
Space → Vehicle: temporarily occupied by. Association · knows another object

Object state after the highlighted operation

{}

function example(input) {
  class ParkingLot {
    constructor(kinds) { this.spaces=kinds.map(kind=>({kind,vehicle:null})); }
    park(id,kind) { if(this.spaces.some(s=>s.vehicle===id)) return "already-parked"; const i=this.spaces.findIndex(s=>s.vehicle===null&&s.kind===kind); if(i<0) return "full"; this.spaces[i].vehicle=id; return "parked:"+i; }
    leave(id) { const s=this.spaces.find(s=>s.vehicle===id); if(!s) return "not-found"; s.vehicle=null; return "released"; }
  }
  const lot=new ParkingLot(input.spaces), results=[];
  for(const action of input.actions) results.push(action.op==="park"?lot.park(action.id,action.kind):lot.leave(action.id));
  return {results,occupants:lot.spaces.map(s=>s.vehicle)};
}

Ready to explore

Press Next to construct the collaborators, then follow the operation and inspect its result.

Step 0 / 4

Textual interaction history

Preparing the design walkthrough…

Implementation and expected output

Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.

Example language

Revised design · Call example(input) with the selected fixture.

Complete JavaScript implementation

function example(input) {
  class ParkingLot {
    constructor(kinds) { this.spaces=kinds.map(kind=>({kind,vehicle:null})); }
    park(id,kind) { if(this.spaces.some(s=>s.vehicle===id)) return "already-parked"; const i=this.spaces.findIndex(s=>s.vehicle===null&&s.kind===kind); if(i<0) return "full"; this.spaces[i].vehicle=id; return "parked:"+i; }
    leave(id) { const s=this.spaces.find(s=>s.vehicle===id); if(!s) return "not-found"; s.vehicle=null; return "released"; }
  }
  const lot=new ParkingLot(input.spaces), results=[];
  for(const action of input.actions) results.push(action.op==="park"?lot.park(action.id,action.kind):lot.leave(action.id));
  return {results,occupants:lot.spaces.map(s=>s.vehicle)};
}

Input

{
  "spaces": [
    "car"
  ],
  "actions": [
    {
      "op": "park",
      "id": "A",
      "kind": "car"
    },
    {
      "op": "leave",
      "id": "A"
    }
  ]
}

Expected contract result

{
  "results": [
    "parked:0",
    "released"
  ],
  "occupants": [
    null
  ]
}

Preparing the design walkthrough…

Try the idea in another setting

A meeting-room scheduler has analogous identity, compatibility, capacity, and release rules, but also needs time-interval conflict checks.

Name the new client contract before adapting the example.
Identify which state belongs to each object and who controls its lifetime.
Write one normal case and one boundary case before extending the design.

Tradeoffs and interview takeaways

This model uses exact-kind matching and a deterministic first-fit policy. A real lot may support bike-in-car fallback, pricing, reservations, and persistence; each is a separate policy or capability.

Common mistake: Allocating without checking existing occupancy or vehicle identity can issue two active spaces to the same vehicle or overwrite another customer.

Explain the choice: ParkingLot owns occupancy; park validates identity and capacity before allocation, while leave releases exactly the matching occupied space.
Challenge your choice: This model uses exact-kind matching and a deterministic first-fit policy. A real lot may support bike-in-car fallback, pricing, reservations, and persistence; each is a separate policy or capability.
Describe a requirement that would make the simpler implementation sufficient.

Design challenge and knowledge check

Preparing the design walkthrough…

Navigation

Course navigation

Parking Lot

What you’ll understand

The idea and when to recognize it

Start with the concrete problem

Scope and extension questions

Responsibilities and contracts

Read the design

Follow the interaction

Implementation and expected output

Try the idea in another setting

Tradeoffs and interview takeaways

Design challenge and knowledge check

Meet the contract across every scenario

Five decisions to remember

Make it your own

Meet the contract across every scenario

Five decisions to remember