= Solution
\b[The system uses the <observer pattern> with a pull-style update.] `Equipment` provides the subject interface and stores registered observers; `GymEquipment` is the concrete subject. `Functionality` is the observer interface, with `Performance` and `Prediction` as concrete observers. Their constructors subscribe them with `addFunctionality(this)`.
When `GymEquipment.updateUserMeasures` is called, it first updates both measurements through `super`, then calls `notifyFunctionalities`. Every subscribed observer receives `update()` and reads the new measurements from its stored equipment reference. `Performance` calculates the current score; `Prediction` calculates the score at time `time+5`, keeping the other quantities fixed. Since observers are prepended to a <list>, notification follows reverse registration order.
The source has two independent implementation defects. `deleteFunctionality(f)` computes `_functionalities diff List(f)` but does not assign it back, so it does not actually unsubscribe anything. The prediction message also contains a physical newline inside an ordinary quoted <Scala> string in the PDF; executable code must join that string, concatenate pieces, or use a multiline string. Neither issue changes the intended <observer pattern>. The source's score is treated as the specified arithmetic expression, not as an independently validated physiological model.
Back to article page
