Vantaggi e svantaggi delle espressioni lambda

1. Vantaggi delle espressioni lambda

Le espressioni lambda non sono solo zucchero sintattico, ma un passo verso lo stile funzionale in Java. Di seguito — i loro reali vantaggi e perché sono così comode nel codice moderno.

Sinteticità ed espressività

Prima delle lambda, un semplice codice «locale» si trasformava in una classe anonima con un sacco di rumore boilerplate. Ad esempio, l’ordinamento delle stringhe per lunghezza:

Prima di Java 8 (classe anonima):

list.sort(new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.length() - b.length();
    }
});

Con un’espressione lambda:

list.sort((a, b) -> a.length() - b.length());

Il codice è più corto e si legge quasi come linguaggio naturale: «ordinare per differenza di lunghezze».

Leggibilità e focus sull’essenziale

Le lambda eliminano il «rumore di servizio» — nomi di classi, graffe superflue, return che non aggiungono significato. Di conseguenza, il codice è più semplice da leggere e mantenere:

names.forEach(name -> System.out.println(name));

Tutto è ovvio: per ogni nome — stamparlo. Qui è utile conoscere metodi delle collezioni come forEach.

Passare il comportamento come parametro

Finalmente è diventato comodo passare un «pezzetto di comportamento» come parametro di un metodo. Questo si percepisce soprattutto con le collezioni, lo Stream API e gli eventi:

Esempio: filtraggio di una lista di numeri

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
numbers.removeIf(n -> n % 2 == 0); // Rimuoviamo i numeri pari

Ottima integrazione con le collezioni e lo Stream API

List<String> words = Arrays.asList("Java", "Python", "C++");
List<String> upper = words.stream()
    .map(s -> s.toUpperCase())
    .collect(Collectors.toList());

Cattura delle variabili (closure)

Le lambda possono «catturare» variabili dal contesto esterno (se sono effettivamente final). Questo consente di creare funzioni al volo che «ricordano» l’ambiente:

int minLength = 3;
list.removeIf(s -> s.length() < minLength);

La variabile minLength è dichiarata all’esterno, ma è disponibile all’interno della lambda.

Una sintassi naturale per eventi e callback

button.addActionListener(e -> System.out.println("Pulsante premuto!"));

Non serve più una classe separata o una classe anonima per una sola riga.

Semplificazione del testing

Si possono inserire rapidamente «stub», senza proliferare classi:

doSomething(() -> System.out.println("Gestore di test"));

2. Svantaggi e limitazioni delle espressioni lambda

Come per qualsiasi strumento, ci sono anche delle insidie.

Difficoltà di debug

Le lambda sono funzioni anonime; in caso di errore, lo stack delle chiamate può non essere evidente. I breakpoint funzionano, ma con lambda lunghe/annidate può essere difficile capire dove sia esattamente il problema.

list.stream()
    .filter(s -> s.length() > 3)
    .map(s -> s.toUpperCase())
    .forEach(System.out::println);

A volte aiuta «sciogliere» la catena in variabili intermedie.

Interfaccia implementata non ovvia

Con overload che accettano interfacce funzionali diverse, il compilatore potrebbe non dedurre quale interfaccia stia implementando la lambda (ad esempio, Runnable con void, oppure Callable con un valore String).

void doSomething(Runnable r) { /* ... */ }
void doSomething(Callable<String> c) { /* ... */ }

// doSomething(() -> "Hello"); // Ambiguità!

Non adatte a logica complessa

Se il corpo della lambda cresce fino a 3–5 righe e oltre (molte condizioni/cicli), il codice perde leggibilità — meglio estrarre la logica in un metodo nominato.

Poco consigliabile:

list.removeIf(s -> s.length() > 3 && s.contains("Java") && s.startsWith("A") && ...);

Meglio:

list.removeIf(this::isComplexCondition);

private boolean isComplexCondition(String s) {
    return s.length() > 3 && s.contains("Java") && s.startsWith("A") && ...;
}

Limitazioni della serializzazione

Le lambda non sono sempre serializzabili. Se è necessario passare la logica tra JVM (sistemi distribuiti), è più affidabile usare classi anonime o nominate, oppure interfacce che supportino esplicitamente Serializable.

Limitazioni dell’ambito (scope)

In una lambda non si possono modificare variabili del metodo esterno, se non sono final o «effettivamente» final.

int count = 0;
list.forEach(s -> count++); // Il compilatore non lo accetterà!

Non adatte al riuso

Le lambda sono funzioni «usa e getta». Se la logica deve essere riutilizzata in più punti — estrarla in un metodo o in una classe con un nome significativo.

Difficoltà con le espressioni lambda annidate

Un annidamento profondo (soprattutto in stream/gestori di eventi) trasforma rapidamente il codice in «spaghetti». Meglio evitare l’annidamento o suddividere in passaggi.

Quando usare le espressioni lambda

• Operazioni brevi e semplici: filtraggio, ordinamento, trasformazione di collezioni, gestione degli eventi.
• Se la lambda supera le 3–5 righe — estrarla in un metodo separato.
• Non usare le lambda per logica di business complessa — date un nome e commenti alla logica.
• Non esagerare con le lambda annidate.
• Estrai la lambda ripetuta in un metodo (o in un metodo statico) e usa un riferimento del tipo this::method oppure ClassName::method.
• Dai nomi significativi ai parametri all’interno della lambda — aumenta la leggibilità.

3. Raccomandazioni pratiche

Scomponi le catene complesse in fasi

Invece di un’unica catena lunga — usa variabili intermedie:

Stream<String> filtered = list.stream().filter(s -> s.length() > 3);
Stream<String> upper = filtered.map(String::toUpperCase);
upper.forEach(System.out::println);

Usa metodi nominati per condizioni complesse

Al posto di una lambda lunga:

list.removeIf(s -> s.length() > 3 && s.contains("Java"));

Meglio:

list.removeIf(this::isJavaString);

private boolean isJavaString(String s) {
    return s.length() > 3 && s.contains("Java");
}

Non aver paura di commentare

Se la lambda non è ovvia — aggiungi un commento prima di essa:

// Rimuoviamo tutte le stringhe che iniziano con uno spazio
list.removeIf(s -> s.startsWith(" "));

4. Errori tipici nell’uso delle espressioni lambda

Errore n. 1: Lambda troppo complessa. I principianti cercano di condensare tutta la logica di business in un’unica lambda. Ne risultano «mostri» da 10 righe, difficili da leggere e mantenere. Non temere di estrarre il codice in metodi!

Errore n. 2: Ambito non ovvio. Si tenta di modificare variabili del metodo esterno dentro la lambda — il compilatore segnala errore. Ricorda: le variabili devono essere final o «effettivamente» final.

Errore n. 3: Overload dei metodi. Se ci sono due overload che accettano interfacce funzionali diverse, il compilatore può non capire quale vuoi chiamare. In tali casi, specifica esplicitamente il tipo:

doSomething((Runnable) () -> System.out.println("Hello"));

Errore n. 4: Abuso di lambda annidate. Le lambda annidate trasformano il codice in «spaghetti» illeggibili. Fermati ed estrai parte del codice in un metodo separato.

Errore n. 5: Uso della lambda dove serve un oggetto a tutti gli effetti. Se è necessario ridefinire più metodi, aggiungere campi o un comportamento non standard — usa una classe anonima o nominata, non una lambda.