# Reference solution — end state after step 3

Derived from [IceCreamForecasting-Refactoring-Kata](https://github.com/emilybache/IceCreamForecasting-Refactoring-Kata)
(same license as the kata applies to the copied `IceCream.java`).

Run with `mvn test` — the approval test passes deterministically without
touching the weather service.

## What changed vs the exercise start

1. Weather loop extracted to `collectExpectedWeather(LongFunction<Boolean>)`
   — a static method whose only "unwanted dependency" is the lambda parameter.
2. Public no-arg `longRangeForecast()` delegates to a new overload that takes
   the weather function, keeping existing callers working.
3. Test passes a pure lambda (`daysForward -> true`) — the original test
   called the no-arg method and was flaky because of `Scorer`'s `Random`.

## Variations to try (for the debrief or a second round)

- `daysForward -> false` (no sunny holidays): scores drop to `+10` only.
- `daysForward -> daysForward == 5` (exactly one sunny holiday, and it is not
  `expectedWeather.get(1)`, so no `+2`): all flavours `10`.
- Delete the `scorer.updateSelection()` call inside the production lambda:
  the approved file does not change — the forecast never reads `Scorer.flavour`.
- Variation end state: skip the overload; make `collectExpectedWeather`
  package-private and test it directly with pure lambdas. Trade-off:
  tests the pure slice but not the composition (scoring loop).