Station Status Board – Task 6
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 reactor team wants the status display to include an emergency shutdown warning. Station policy requires that if reactor cooling efficiency drops below 30%, an automatic shutdown protocol must be initiated. Currently, engineers have to mentally check whether the current reading is below this critical level. They want the program to explicitly flag this condition whenever someone queries the reactor status.
The power distribution team has a different need. They want to track voltage trends over time. If voltage has been declining steadily over recent measurements, it might indicate a developing problem even if the current reading is still above the critical threshold. They want the status display to warn about downward trends so preventive maintenance can be scheduled.
The life support team needs per-crew-member calculations. The raw oxygen measurement is useful, but what engineers really need to know is whether there's enough oxygen per person. With the current crew size of 47, they want the status display to automatically calculate and show the oxygen level per crew member.
The chief engineer mentions that the navigation team faced a similar challenge when they needed different calculations for different types of celestial objects. She shows you a snippet from their tracking system:
void displayObjectInfo() {
System.out.println("Tracking: " + objectName);
System.out.println("Distance: " + distance + "km");
if (objectName.equals("Mars")) {
System.out.println("Orbital period: 687 days");
} else if (objectName.equals("Luna")) {
System.out.println("Orbital period: 27 days");
}
}
"They check which object they're tracking and add specific information accordingly," she explains. "You'll need something similar for the different subsystem types."
Your task is to add these subsystem-specific features to your monitoring program. When a user queries ReactorCooling, the program should check if emergency shutdown is required. When they query PowerDistribution, it should analyze trends. When they query LifeSupport, it should calculate per-person oxygen levels. Other subsystems should display normally without these extra checks.
The status file format is unchanged:
ReactorCooling 42% NORMAL 35% 58% 35% 127 14:23
PowerDistribution 119V NORMAL 115V 124V 117V 134 14:23
LifeSupport 198000ppm NORMAL 195000ppm 205000ppm 195000ppm 128 14:23
Navigation 0.02deg WARNING 0.00deg 0.08deg 0.05deg 131 14:23
ThermalRegulation 18C NORMAL 16C 22C 15C 129 14:23
WasteRecycling 87% NORMAL 82% 95% 80% 126 14:23
CommArray 94% NORMAL 89% 98% 85% 133 14:23
DockingClamps 3201kPa NORMAL 3150kPa 3280kPa 3100kPa 130 14:23
For simplicity, you can simulate trend analysis by comparing the current reading to the average of min and max values—if the current value is closer to the minimum, consider it a downward trend. The program should produce output like this:
Enter subsystem name (or 'quit' to exit): ReactorCooling
ReactorCooling: 42% [NORMAL]
Range: 35% to 58%
Critical threshold: 35%
Measurements recorded: 127
Last updated: 14:23
Enter subsystem name (or 'quit' to exit): PowerDistribution
PowerDistribution: 119V [NORMAL]
Range: 115V to 124V
Critical threshold: 117V
Measurements recorded: 134
Last updated: 14:23
?? Voltage trending downward - schedule maintenance check
Enter subsystem name (or 'quit' to exit): LifeSupport
LifeSupport: 198000ppm [NORMAL]
Range: 195000ppm to 205000ppm
Critical threshold: 195000ppm
Measurements recorded: 128
Last updated: 14:23
Oxygen per crew member (47 total): 4212ppm
Enter subsystem name (or 'quit' to exit): quit
Session ended.
As you implement this, you'll likely add conditional logic that checks the subsystem name and performs different operations based on which subsystem is being queried. You might add methods to your SubsystemData class that check if (this.name.equals("ReactorCooling")) and then perform reactor-specific logic, or you might handle this in your query display code. Either way, you'll notice that the code becomes harder to maintain. Each time a new subsystem needs special behavior, you'll need to add another conditional branch. The SubsystemData class is supposed to represent all subsystems uniformly, but now it's filled with special cases.
Looking ahead: The chief engineer reviews your implementation and acknowledges that it works, but expresses concern about the approach. "We're putting subsystem-specific logic in a class that's supposed to be general," she says. "If we keep adding special cases, this class will become enormous and fragile. What we really have here are different types of monitors that share common structure but have specialized behavior. There's a programming technique specifically designed for this situation—a way to define a general monitor class that captures the shared logic, while allowing specialized subclasses to add their unique features." She suggests you'll explore this approach in the next task.