We are writing software to collect and manage data on how fast racers can complete obstacle courses.
An obstacle course is a series of difficult physical challenges (like walls, hurdles, and ponds) that a racer must go through. Each course consists of multiple obstacles.
The software stores how long it takes for racers to finish each obstacle, and provides useful statistics based on those times.
Definitions:
- A
runis a particular attempt to complete an entire obstacle course. - A
run collectionis a group of runs on a particular course by the user. - An
obstacleis a portion of a course.
We track how long it takes to finish each portion of the course.
For example, here are some times for an obstacle course with four obstacles:
Obstacles: 01 02 03 04
Run 1: 3 4 5 6 (total: 18 seconds)
Run 2: 4 4 4 5 (total: 17 seconds)
Run 3: 5 5 3 (13 seconds, but run is incomplete)All of these runs for one obstacle course (including the incomplete run) make up a run collection.
You are given the following classes:
Course: data about a particular course.Run: data and methods about a single run of a course.RunCollection: data for a number of runs of a particular course, and methods for getting useful statistics about all runs of a course.
Run should support adding obstacle times one by one, track whether the run is complete, and return the total elapsed time so far.
RunCollection should validate that all added runs belong to the same course and be able to compute the personal best time across all runs.
Example test data:
obstacle_data = [[3, 4, 5, 6], [4, 4, 4, 5], [5, 5, 3]]test_course = Course("Test course", 4)- Expected number of runs:
3 - Expected personal best:
17
This problem is an object-oriented modeling exercise around obstacle-course timing data. You implement `Course`, `Run`, and `RunCollection`, where a run records obstacle times one by one, knows when it becomes complete, and reports its total elapsed time. The collection validates that every run belongs to the same course and computes statistics such as the personal best. A straightforward list-based design is enough, with simple validation and aggregation over the stored runs.
