Dlaczego powinienem używać „operacji funkcjonalnych” zamiast pętli for?

for (Canvas canvas : list) {
}

NetBeans sugeruje użycie „operacji funkcjonalnych”:

list.stream().forEach((canvas) -> {
});

Ale dlaczego jest to preferowane ? Jeśli tak, to trudniej jest je przeczytać i zrozumieć. Dzwonisz stream(), a następnie forEach()używasz wyrażenia lambda z parametrem canvas. Nie rozumiem, jak to jest ładniejsze niż forpętla w pierwszym fragmencie.

Oczywiście mówię tylko z estetyki. Być może brakuje mi tutaj przewagi technicznej. Co to jest? Dlaczego zamiast tego powinienem użyć drugiej metody?

Strumienie zapewniają znacznie lepszą abstrakcję dla kompozycji różnych operacji, które chcesz wykonywać na podstawie kolekcji lub strumieni danych, które nadchodzą. Zwłaszcza, gdy trzeba mapować elementy, filtrować je i konwertować.

Twój przykład nie jest zbyt praktyczny. Rozważ następujący kod z witryny Oracle .

List<Transaction> groceryTransactions = new Arraylist<>();
for(Transaction t: transactions){
  if(t.getType() == Transaction.GROCERY){
    groceryTransactions.add(t);
  }
}
Collections.sort(groceryTransactions, new Comparator(){
  public int compare(Transaction t1, Transaction t2){
    return t2.getValue().compareTo(t1.getValue());
  }
});
List<Integer> transactionIds = new ArrayList<>();
for(Transaction t: groceryTransactions){
  transactionsIds.add(t.getId());
}

można zapisać za pomocą strumieni:

List<Integer> transactionsIds = 
    transactions.stream()
                .filter(t -> t.getType() == Transaction.GROCERY)
                .sorted(comparing(Transaction::getValue).reversed())
                .map(Transaction::getId)
                .collect(toList());

Druga opcja jest znacznie bardziej czytelna. Więc kiedy zagnieżdżasz pętle lub różne pętle wykonujące częściowe przetwarzanie, jest to bardzo dobry kandydat do użycia interfejsu API Streams / Lambda.

Kolejną zaletą korzystania z funkcjonalnego API przesyłania strumieniowego jest to, że ukrywa on szczegóły implementacji. Opisuje tylko, co należy zrobić, a nie jak. Ta zaleta staje się oczywista, gdy przyjrzymy się zmianom, które należy wprowadzić, aby zmienić z jednowątkowego na równoległe wykonywanie kodu. Wystarczy zmienić .stream()się .parallelStream().

Jeśli tak, to trudniej jest je przeczytać i zrozumieć.

To jest bardzo subiektywne. Uważam, że druga wersja jest znacznie łatwiejsza do odczytania i zrozumienia. Pasuje do tego, jak robią to inne języki (np. Ruby, Smalltalk, Clojure, Io, Ioke, Seph), wymaga mniej pojęć do zrozumienia (jest to zwykłe wywołanie metody, jak każdy inny, podczas gdy pierwszy przykład to specjalistyczna składnia).

Jeśli już, to kwestia znajomości.