Backed up Vehicles Intersection - Exercise

Objective

Implement a VehicleQueue that records vehicle events waiting on one approach to the traffic intersection. The class must preserve first-in, first-out behavior, report both vehicle count and physical queue length, and keep queue storage separate from vehicle creation and signal-control policy.

Background and Design Context

One VehicleQueue type should support north, south, east, and west approaches through separate instances. A VehicleFactory or FlyweightVehicleFactory creates vehicle descriptions; it does not own the queue. Each queued event retains occurrence-specific information such as identifier and arrival time even when several events share one immutable vehicle-type flyweight.

Functional Requirements and Constraints

1. Create a VehicleQueue class backed by a real FIFO collection. In modern Java, prefer ArrayDeque; in C++, std::deque or std::queue is appropriate.
2. Inject the vehicle creator through the constructor. Do not access a mutable global factory or construct a new factory during every arrival.
3. Represent the arrival probability as a validated value between 0.0 and 1.0. Inject the random source or an arrival policy so tests can be deterministic.
4. Implement enter() so one simulation tick can add at most one event according to the configured arrival policy.
5. Implement leave() so it removes and returns only the oldest waiting event. Define an explicit empty-queue result rather than throwing an accidental collection exception.
6. Implement getSize() to return the number of queued events and getLength() to return their combined physical length in meters.
7. Provide a read-only diagnostic representation or list() operation without exposing the mutable collection.
8. Keep traffic-light scheduling outside this class. Clearing the complete queue when a light turns green is not acceptable because departures occur over time.

Required Deliverables

Submit the queue class, any small interface or event type required by the design, and focused tests. Include a short explanation of collection choice, factory ownership, empty-queue behavior, and how deterministic arrival tests are achieved. Your response may use Java or C++, but it must be internally consistent and compilable with a current language version.

Testing and Verification

• Enqueue three known events and assert they leave in the same order.
• Verify size and total physical length before and after each departure.
• Verify that an empty departure returns the documented empty result.
• Use a deterministic random source to test probability 0.0, probability 1.0, and one intermediate sequence.
• Verify that two queue instances do not share mutable event storage.
• If flyweights are used, verify that shared vehicle descriptions remain immutable while event identities remain distinct.

Evaluation Criteria

The solution is evaluated for FIFO correctness, explicit ownership, separation of responsibilities, meaningful validation, deterministic tests, and clear handling of empty queues. A solution that only stores strings, clears an entire direction at once, hides random creation in global state, or exposes its mutable collection does not satisfy the exercise.