Your Name
77ae05c28c
The refactoring is now published as Slice on sammancoaching.org: https://sammancoaching.org/refactorings/slice.html - git mv ideas/split-loop-with-lambda -> ideas/slice-with-lambda - rename learning-hour file and update frontmatter name - update paths in tools/rehearse scripts and report title - update prose: 'Split Loop with Lambda' -> 'Slice with Lambda' in learning hour, exercise READMEs, storyboard, solution comments - link the published Slice refactoring from the pattern draft
1.4 KiB
1.4 KiB
Reference solution — end state after step 3
Derived from 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
- Weather loop extracted to
collectExpectedWeather(LongFunction<Boolean>)— a static method whose only "unwanted dependency" is the lambda parameter. - Public no-arg
longRangeForecast()delegates to a new overload that takes the weather function, keeping existing callers working. - Test passes a pure lambda (
daysForward -> true) — the original test called the no-arg method and was flaky because ofScorer'sRandom.
Variations to try (for the debrief or a second round)
daysForward -> false(no sunny holidays): scores drop to+10only.daysForward -> daysForward == 5(exactly one sunny holiday, and it is notexpectedWeather.get(1), so no+2): all flavours10.- Delete the
scorer.updateSelection()call inside the production lambda: the approved file does not change — the forecast never readsScorer.flavour. - Variation end state: skip the overload; make
collectExpectedWeatherpackage-private and test it directly with pure lambdas. Trade-off: tests the pure slice but not the composition (scoring loop).