Picture a weather station that already understands one kind of thermometer: ask for Celsius and get a Celsius reading back. A newly purchased sensor is perfectly usable, but its API reports Fahrenheit through a differently named method. Rewriting the station or the vendor's sensor would make either side depend on the other.
Your task is deliberately focused: implement only the FahrenheitSensorAdapter class. The Thermometer contract, both sensor classes, and the WeatherStation test harness are already implemented in the starter code.
The adapter must provide this behavior (method names follow each language's starter code):
FahrenheitSensorAdapter(sensor) receives and stores a FahrenheitSensor.Thermometer contract, so the station can use it anywhere it uses a Celsius sensor.getCelsius() asks the wrapped sensor for its current Fahrenheit reading and returns (F - 32) * 5 / 9.The provided WeatherStation registers Celsius sensors directly and wraps Fahrenheit sensors with your adapter. It then keeps both in one Thermometer collection and treats them identically. The station also handles indexes, formatting, and finding the warmest reading; you do not need to reimplement any of that orchestration.
The examples use WeatherStation operations because it is the public test harness. Your code changes belong only inside FahrenheitSensorAdapter.
Input:
Output:
Explanation: The Celsius sensor reports 25 degrees directly. The Fahrenheit sensor reports 212, and the station reads 100 back through the adapter without knowing a conversion took place.
Input:
Output:
Explanation: A 50 F sensor is 10 C, so the 30 C sensor is the warmer of the two even though 50 is the larger raw number. No sensor holds index 9, so reading returns UNKNOWN.
-100.0 <= celsius <= 100.0-148.0 <= fahrenheit <= 212.0-20 <= index <= 20100 calls in total are made across all methods.Only FahrenheitSensorAdapter is unfinished. Define the complete adapter at the marked location. Every other type is already implemented; do not rewrite it.
Full marks when `FahrenheitSensorAdapter` implements the thermometer contract and stores the `FahrenheitSensor` supplied to its constructor. Lose points heavily when it extends the vendor sensor, creates a replacement sensor, or fails to expose the exact `getCelsius` method.
Full marks when every `getCelsius` call reads the wrapped sensor and returns `(F - 32) * 5 / 9` using floating-point arithmetic. Lose points when the reading is cached at construction, returned as Fahrenheit, or converted with an inverted or integer-truncated ratio.
Full marks when the adapter only translates and delegates, with no station logic, formatting, unit flags, or output to stdout. Lose points for duplicating the supplied harness or moving conversion responsibilities outside the adapter.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new WeatherStation() | null |
| addCelsiusSensor(25) | 0 |
| sensorCount() | 1 |
| readCelsius(0) | 25 |
| reading(0) | "25.0 C" |
| addFahrenheitSensor(212) | 1 |
| readCelsius(1) | 100 |
| reading(1) | "100.0 C" |
| sensorCount() | 2 |
The Celsius sensor reports 25 degrees directly. The Fahrenheit sensor reports 212, and the station reads 100 back through the adapter without knowing a conversion took place.
Run checks these cases. Submit also runs a larger hidden set.

