Refactoring for DRY

[Richard Warburton]

> But aggressively I might optimize by only doing a single pass:
>
>     double sum = people.parallelStream().flatMap( (Person p,
> Consumer<Person> c) -> {
>       if (p.getAge() >= 12 && p.getAge() < 65) {
>         if (p.hasCoupon()) {
>           p.setPrice(9.25);
>         } else {
>           p.setPrice(7.25);
>         }
>       } else {
>         p.setPrice(5.25);
>       }
>       p.display();
>       c.accept(p);
>     }).map(Person::getPrice)
>             .collect(Collectors.toDoubleSummaryStatistics(d ->
> d)).getSum();
>

Even leaving aside the question of tee()/peek() is this code really a good
candidate to be run in parallel?

Its pretty unreasonable to expect display to not have side effects, does
their ordering matter, and the consumer needs to be thread-safe.  Does this
not get people away from the driving motivation of minimising and
controlling side effects in order to make safe concurrent code easier to
write?

I'm really wondering because to my mind this is the kind of code I'd
recommend people don't write with lambdas.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>