Erebos Station

English further down vvvvvvvv

Shortly after arriving on Erebos Station, you are given access to the reactor control wing. The main reactor is old but stable, provided its cooling system operates within acceptable limits. To ensure this, the station continuously measures cooling efficiency and writes the results to a diagnostic log file.

Over the past few days, your cooling monitor has proven useful. The crew now checks the summary report each shift to confirm that the reactor is operating safely. But a new problem has emerged.

Your cooling reports have become essential to station operations. The crew relies on them every shift, and the critical threshold warnings have already prevented two potential incidents. But the station's chief engineer has noticed something troubling.

Your monitoring programs have proven valuable enough that the station's chief engineer wants to expand their scope. Until now, you have been tracking individual subsystems one at a time, running separate programs for reactor cooling, power distribution, and other systems. This approach worked when each system was monitored independently, but it has become inefficient.

The status summary program you built has become essential to station operations. The engineering team runs it every hour and reviews the output to ensure all systems are functioning properly. But a new workflow has emerged that the current program cannot support.

The query system you built has become indispensable. Crew members across the station rely on it to check subsystem status throughout their shifts. But the chief engineer has noticed something about how different programmers have implemented the lookup functionality, and she wants to share an important technique with you.

The HashMap-based query system has been running smoothly for several weeks, and the crew has come to rely on it for quick subsystem checks. However, the station director has requested expanded reporting capabilities. She wants the status board to show not just current readings, but also the full operational context for each subsystem: the highest and lowest values recorded, how many measurements have been taken, when the data was last updated, and what threshold defines critical conditions.

The seven-HashMap solution from the previous task works, but as the chief engineer predicted, it has become a maintenance burden. When adding new subsystems to the monitoring system, engineers frequently forget to update all seven HashMaps, leading to incomplete data. When querying subsystems, the code is verbose and repetitive. The station's software review board has flagged this pattern as problematic and asked you to refactor it.

The class-based status board has been working well, and the engineering teams appreciate how much cleaner the code has become. However, as the chief engineer predicted, the individual subsystem teams have started requesting specialized features for their monitoring displays. These requests are reasonable and would genuinely improve safety and efficiency, but they present a design challenge.

The subsystem-specific features you added in the previous task have proven valuable. The reactor team appreciates the shutdown warnings, the power team uses the trend analysis for maintenance scheduling, and the life support team relies on the per-person oxygen calculations. However, as more teams request similar specialized features, the conditional logic in your code has grown unwieldy. The chief engineer wants to show you a better way to organize this type of code.