Le espressioni lambda hanno un uso diverso dal salvataggio di righe di codice?

Le espressioni lambda hanno un uso diverso dal salvataggio di righe di codice?

Ci sono funzioni speciali fornite da lambda che hanno risolto problemi che non erano facili da risolvere? L'utilizzo tipico che ho visto è che invece di scrivere questo:

Comparator<Developer> byName = new Comparator<Developer>() {
  @Override
  public int compare(Developer o1, Developer o2) {
    return o1.getName().compareTo(o2.getName());
  }
};

Possiamo usare un'espressione lambda per abbreviare il codice:

Comparator<Developer> byName =
(Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName());

Le espressioni lambda non cambiano l'insieme di problemi che puoi risolvere con Java in generale, ma sicuramente facilitano la risoluzione di alcuni problemi, proprio per lo stesso motivo per cui non programmiamo più in linguaggio assembly. Rimuovere le attività ridondanti dal lavoro del programmatore semplifica la vita e consente di fare cose che altrimenti non toccheresti nemmeno, solo per la quantità di codice che dovresti produrre (manualmente).

Ma le espressioni lambda non salvano solo righe di codice. Le espressioni lambda ti consentono di definire funzioni , qualcosa per cui potresti usare classi interne anonime come soluzione alternativa, ecco perché puoi sostituire classi interne anonime in questi casi, ma non in generale.

In particolare, le espressioni lambda sono definite indipendentemente dall'interfaccia funzionale a cui verranno convertite, quindi non ci sono membri ereditati a cui potrebbero accedere, inoltre, non possono accedere all'istanza del tipo che implementa l'interfaccia funzionale. All'interno di un'espressione lambda, thise superhanno lo stesso significato del contesto circostante, vedere anche questa risposta . Inoltre, non è possibile creare nuove variabili locali che ombreggiano le variabili locali del contesto circostante. Per il compito previsto di definire una funzione, questo rimuove molte fonti di errore, ma implica anche che per altri casi d'uso, potrebbero esserci classi interne anonime che non possono essere convertite in un'espressione lambda, anche se implementa un'interfaccia funzionale.

Inoltre, il costrutto new Type() { … }garantisce di produrre una nuova istanza distinta (come newsempre fa). Le istanze anonime della classe interna mantengono sempre un riferimento alla loro istanza esterna se create in un non staticcontesto. Al contrario, le espressioni lambda catturano solo un riferimento a thisquando necessario, cioè se accedono thiso un non staticmembro. E producono istanze di un'identità intenzionalmente non specificata, che consente all'implementazione di decidere in fase di runtime se riutilizzare istanze esistenti (vedere anche " Un'espressione lambda crea un oggetto sull'heap ogni volta che viene eseguita? ").

Queste differenze si applicano al tuo esempio. Il tuo costrutto della classe interna anonima produrrà sempre una nuova istanza, inoltre potrebbe catturare un riferimento all'istanza esterna, mentre la tua (Developer o1, Developer o2) -> o1.getName().compareTo(o2.getName())è un'espressione lambda non di acquisizione che verrà valutata come un singleton nelle implementazioni tipiche. Inoltre, non produce un .classfile sul tuo disco rigido.

Date le differenze riguardanti sia la semantica che le prestazioni, le espressioni lambda possono cambiare il modo in cui i programmatori risolveranno determinati problemi in futuro, ovviamente, anche a causa delle nuove API che abbracciano idee di programmazione funzionale utilizzando le nuove funzionalità del linguaggio. Vedere anche Espressione lambda Java 8 e valori di prima classe .

I linguaggi di programmazione non sono per le macchine da eseguire.

Sono per i programmatori su cui riflettere .

Le lingue sono una conversazione con un compilatore per trasformare i nostri pensieri in qualcosa che una macchina può eseguire. Una delle principali lamentele su Java da parte di persone che vengono ad esso da altre lingue (o lasciano che per altre lingue) usato per essere che costringe un certo modello mentale sul programmatore (cioè tutto è una classe).

Non ho intenzione di valutare se sia un bene o un male: tutto è un compromesso. Ma i lambda Java 8 consentono ai programmatori di pensare in termini di funzioni , cosa che prima non si poteva fare in Java.

È la stessa cosa di un programmatore procedurale che impara a pensare in termini di classi quando arriva a Java: li vedi spostarsi gradualmente da classi che sono strutture glorificate e hanno classi `` helper '' con un mucchio di metodi statici e passare a qualcosa che assomiglia più da vicino a un design OO razionale (mea culpa).

Se li consideri solo un modo più breve per esprimere classi interne anonime, probabilmente non li troverai molto impressionanti nello stesso modo in cui il programmatore procedurale sopra probabilmente non pensava che le classi fossero un grande miglioramento.

Il salvataggio di righe di codice può essere visto come una nuova funzionalità, se consente di scrivere una parte sostanziale di logica in un modo più breve e più chiaro, che richiede meno tempo per la lettura e la comprensione da parte degli altri.

Senza espressioni lambda (e / o riferimenti a metodi) le Streampipeline sarebbero state molto meno leggibili.

Pensa, ad esempio, come Streamsarebbe stata la seguente pipeline se sostituissi ogni espressione lambda con un'istanza di classe anonima.

List<String> names =
    people.stream()
          .filter(p -> p.getAge() > 21)
          .map(p -> p.getName())
          .sorted((n1,n2) -> n1.compareToIgnoreCase(n2))
          .collect(Collectors.toList());

Sarebbe:

List<String> names =
    people.stream()
          .filter(new Predicate<Person>() {
              @Override
              public boolean test(Person p) {
                  return p.getAge() > 21;
              }
          })
          .map(new Function<Person,String>() {
              @Override
              public String apply(Person p) {
                  return p.getName();
              }
          })
          .sorted(new Comparator<String>() {
              @Override
              public int compare(String n1, String n2) {
                  return n1.compareToIgnoreCase(n2);
              }
          })
          .collect(Collectors.toList());

È molto più difficile da scrivere rispetto alla versione con espressioni lambda ed è molto più soggetta a errori. È anche più difficile da capire.

E questa è una pipeline relativamente breve.

Per renderlo leggibile senza espressioni lambda e riferimenti al metodo, avresti dovuto definire variabili che contengano le varie istanze dell'interfaccia funzionale utilizzate qui, il che avrebbe diviso la logica della pipeline, rendendola più difficile da capire.

Iterazione interna

Durante l'iterazione delle raccolte Java, la maggior parte degli sviluppatori tende a ottenere un elemento e quindi a elaborarlo . Cioè, togli quell'elemento e poi usalo, o reinseriscilo, ecc. Con le versioni precedenti alla 8 di Java, puoi implementare una classe interna e fare qualcosa come:

numbers.forEach(new Consumer<Integer>() {
    public void accept(Integer value) {
        System.out.println(value);
    }
});

Ora con Java 8 puoi fare di meglio e meno prolisso con:

numbers.forEach((Integer value) -> System.out.println(value));

o meglio

numbers.forEach(System.out::println);

Comportamenti come argomenti

Indovina il seguente caso:

public int sumAllEven(List<Integer> numbers) {
    int total = 0;

    for (int number : numbers) {
        if (number % 2 == 0) {
            total += number;
        }
    } 
    return total;
}

Con l' interfaccia Java 8 Predicate puoi fare di meglio in questo modo:

public int sumAll(List<Integer> numbers, Predicate<Integer> p) {
    int total = 0;

    for (int number : numbers) {
        if (p.test(number)) {
            total += number;
        }
    }
    return total;
}

Chiamandolo come:

sumAll(numbers, n -> n % 2 == 0);

Fonte: DZone - Perché abbiamo bisogno delle espressioni Lambda in Java

Ci sono molti vantaggi nell'usare lambda invece della classe interna come di seguito:

• Rendi il codice più compatto ed espressivo senza introdurre più semantica della sintassi del linguaggio. hai già fornito un esempio nella tua domanda.

• Usando le espressioni lambda sei felice di programmare con operazioni in stile funzionale sui flussi di elementi, come le trasformazioni di riduzione della mappa nelle raccolte. vedere la documentazione dei pacchetti java.util.function e java.util.stream .

• Non esiste un file di classi fisiche generato per lambda dal compilatore. Pertanto, riduce le dimensioni delle applicazioni fornite. Come la memoria assegna a lambda?

• Il compilatore ottimizzerà la creazione di lambda se lambda non accede a variabili al di fuori del suo ambito, il che significa che l'istanza lambda viene creata solo una volta dalla JVM. per maggiori dettagli puoi vedere la risposta di @ Holger alla domanda La memorizzazione nella cache dei riferimenti al metodo è una buona idea in Java 8? .

• Lambdas può implementare interfacce multi marker oltre all'interfaccia funzionale, ma le classi interne anonime non possono implementare più interfacce, ad esempio:

  //                 v--- create the lambda locally.
  Consumer<Integer> action = (Consumer<Integer> & Serializable) it -> {/*TODO*/};

I lambda sono solo zucchero sintattico per classi anonime.

Prima di lambda, le classi anonime possono essere utilizzate per ottenere lo stesso risultato. Ogni espressione lambda può essere convertita in una classe anonima.

Se stai usando IntelliJ IDEA, può eseguire la conversione per te:

• Posiziona il cursore nel lambda
• Premi ALT / OPZIONE + INVIO

Per rispondere alla tua domanda, il fatto è che lambda non ti consente di fare nulla che non potresti fare prima di java-8, piuttosto ti consente di scrivere codice più conciso . Il vantaggio di questo è che il tuo codice sarà più chiaro e più flessibile.

Una cosa che non vedo ancora menzionata è che un lambda ti consente di definire la funzionalità dove viene utilizzato .

Quindi, se hai qualche semplice funzione di selezione non è necessario metterla in un posto separato con un mucchio di boilerplate, scrivi semplicemente un lambda che sia conciso e localmente rilevante.

Sì, ci sono molti vantaggi.

• Non è necessario definire l'intera classe, possiamo passare l'implementazione della funzione stessa come riferimento.
  • La creazione interna della classe creerà il file .class mentre se usi lambda, la creazione della classe viene evitata dal compilatore perché in lambda stai passando l'implementazione della funzione invece della classe.
• La riutilizzabilità del codice è maggiore rispetto a prima
• E come hai detto, il codice è più breve della normale implementazione.