Refactoring for DRY (original) (raw)
Richard Warburton richard.warburton at gmail.com
Tue Apr 9 03:02:16 PDT 2013
- Previous message: Refactoring for DRY
- Next message: Refactoring for DRY
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
But aggressively I might optimize by only doing a single pass:
double sum = people.parallelStream().flatMap( (Person p, Consumer 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>
- Previous message: Refactoring for DRY
- Next message: Refactoring for DRY
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]