interfacce funzionali package java.util.function

[andbin]

p.s. dal punto di vista puramente discorsivo dire "metodi a reference" e dire "reference a metodi" è la stessa cosa?

"metodi a reference" non ha senso, non dice nulla di significativo. "reference a metodi" può avere senso in generale. Ma tieni presente che in Java, a livello di JVM, non esistono i riferimenti a metodi.

L'espressione TestCitta::getCitta se noti viene sostanzialmente passata al parametro Predicate<Citta> p di getCittaFiltrate.
Quello che succede è che a getCittaFiltrate viene passato un oggetto che in un qualche modo implementa la interfaccia Predicate e il cui metodo boolean test(T t) (dove T viene preso come Citta) contiene la invocazione al tuo metodo getCitta di TestCitta. Ma tutto questo viene fatto "dietro le quinte" dal compilatore.

[newutente]

Ma tieni presente che in Java, a livello di JVM, non esistono i riferimenti a metodi.

e questo cosa comporta? Cioè se a livello di JVM non esistono i reference a metodi come fa il codice che contiene i reference a metodi ad essere "tradotto" in un linguaggio comprensibile dalla macchina?

L'espressione TestCitta::getCitta se noti viene sostanzialmente passata al parametro Predicate<Citta> p di getCittaFiltrate.
Quello che succede è che a getCittaFiltrate viene passato un oggetto che in un qualche modo implementa la interfaccia Predicate e il cui metodo boolean test(T t) (dove T viene preso come Citta) contiene la invocazione al tuo metodo getCitta di TestCitta. Ma tutto questo viene fatto "dietro le quinte" dal compilatore.

Vediamo se ho capito come funziona questa interfaccia funzionale Predicate.
Se ho capito bene questa interfaccia permette semplicemente di fare dei controlli e restituire tramite l'unico metodo astratto test() un booleano.
Per prima cosa c'è bisogno di un metodo che come parametro di input prenda un oggetto Predicate<T> e questo perchè all'interno del metodo bisogna richiamare su quell'oggetto il metodo test(). In poche parole quello che accade in getCittaFiltrate.
Successivamente bisogna definire un altro metodo che deve restituire sempre un booleano, perchè appunto parliamo di controlli che lavorano su booleani. In poche parole quello che fa getCitta.
Infine per utilizzare il tutto bisogna passare, durante la chiamata al metodo precedentemente creato che definisce un oggetto Predicate in input, il metodo creato per ultimo (il getCitta per intenderci) in modo da far capire al compilatore che tipo di controllo dovrà essere effettuato.
Quindi diciamo che questa interfaccia permette di creare dei "filtri" al volo con poche righe di codice perchè è sufficiente passare poi al metodo (es. getCittaFiltrate) il "filtro" (es. getCitta).
E' corretto?

[andbin]

e questo cosa comporta? Cioè se a livello di JVM non esistono i reference a metodi come fa il codice che contiene i reference a metodi ad essere "tradotto" in un linguaggio comprensibile dalla macchina?

Perché c'è molto "dietro" le lambda expression e method reference! E il compilatore effettua un bel po' di cose di nascosto.

Tieni presente che Java non è un linguaggio "funzionale". E non lo è ancora adesso, in senso stretto, nemmeno con Java 8. Nei linguaggi funzionali la "funzione" è un tipo di prima classe, che può essere passato, ritornato, assegnato alla stregua di altri tipi di dati.
In Java no, non è così, almeno per il momento. Per introdurre lambda expression/method reference nel linguaggio hanno dovuto fare delle scelte, importanti e sicuramente non banali, più che altro per allinearsi a quello che è il type-system attuale di Java, fatto solo di primitivi e classi/interfacce(/enum/annotazioni, e anche array) e basta. Per farlo hanno tirato fuori innanzitutto il concetto di "interfaccia funzionale".
Quando tu passi ad un metodo l'espressione TestCitta::getCitta, non stai passando (per ora, almeno in Java 8) un riferimento a getCitta! Sotto-sotto viene creato un oggetto che implementa la interfaccia indicata nel parametro, che deve avere il singolo metodo astratto che corrisponde, come forma, al tuo getCitta.

Se vuoi andare molto a fondo in queste cose, allora es.:
- Maurice Naftalin's Lambda FAQ
- Java 8 Lambdas - A Peek Under the Hood
- Java 8: The First Taste of Lambdas

E questi comunque sono aspetti parecchio "avanzati" ....

Vediamo se ho capito come funziona questa interfaccia funzionale Predicate.

In informatica (ma anche in logica matematica se non sbaglio) un "predicato" è una funzione che dato un valore X restituisce un booleano vero/falso. E l'uso più ovvio e naturale è per realizzare dei filtri al fine di accettare/rifiutare i valori.

Quindi diciamo che questa interfaccia permette di creare dei "filtri" al volo con poche righe di codice perchè è sufficiente passare poi al metodo (es. getCittaFiltrate) il "filtro" (es. getCitta).
E' corretto?

Detto così, si ok è corretto.

Cerca anche di vedere la questione dell'inferenza dei tipi:

- il parametro è Predicate<Citta>
- Predicate ha un metodo astratto boolean test(T t) (questo è il metodo "funzionale")
- quindi la firma da implementare è boolean test(Citta)
- passi un "riferimento" (come descritto prima) ad un metodo public static boolean getCitta(Citta)

Come vedi (parti in rosso) la forma corrisponde, quindi per il compilatore è ok.
Il concetto vale per Predicate e per tutte le altre intefacce "funzionali".

[newutente]

Perché c'è molto "dietro" le lambda expression e method reference! E il compilatore effettua un bel po' di cose di nascosto.

Tieni presente che Java non è un linguaggio "funzionale". E non lo è ancora adesso, in senso stretto, nemmeno con Java 8. Nei linguaggi funzionali la "funzione" è un tipo di prima classe, che può essere passato, ritornato, assegnato alla stregua di altri tipi di dati.
In Java no, non è così, almeno per il momento. Per introdurre lambda expression/method reference nel linguaggio hanno dovuto fare delle scelte, importanti e sicuramente non banali, più che altro per allinearsi a quello che è il type-system attuale di Java, fatto solo di primitivi e classi/interfacce(/enum/annotazioni, e anche array) e basta. Per farlo hanno tirato fuori innanzitutto il concetto di "interfaccia funzionale".
Quando tu passi ad un metodo l'espressione TestCitta::getCitta, non stai passando (per ora, almeno in Java 8) un riferimento a getCitta! Sotto-sotto viene creato un oggetto che implementa la interfaccia indicata nel parametro, che deve avere il singolo metodo astratto che corrisponde, come forma, al tuo getCitta.

Grazie per la spiegazione.

Se vuoi andare molto a fondo in queste cose, allora es.:
- Maurice Naftalin's Lambda FAQ
- Java 8 Lambdas - A Peek Under the Hood
- Java 8: The First Taste of Lambdas

E questi comunque sono aspetti parecchio "avanzati" ....

sono aspetti un tantino avanzati e per il momento vorrei tralasciarli però grazie per i link.

In informatica (ma anche in logica matematica se non sbaglio) un "predicato" è una funzione che dato un valore X restituisce un booleano vero/falso. E l'uso più ovvio e naturale è per realizzare dei filtri al fine di accettare/rifiutare i valori.


Detto così, si ok è corretto.

Cerca anche di vedere la questione dell'inferenza dei tipi:

- il parametro è Predicate<Citta>
- Predicate ha un metodo astratto boolean test(T t) (questo è il metodo "funzionale")
- quindi la firma da implementare è boolean test(Citta)
- passi un "riferimento" (come descritto prima) ad un metodo public static boolean getCitta(Citta)

Come vedi (parti in rosso) la forma corrisponde, quindi per il compilatore è ok.
Il concetto vale per Predicate e per tutte le altre intefacce "funzionali".

Ah ecco, quindi è un discorso valido per tutte le interfacce funzionali. Per certi versi potrei seguire quindi questo "schema" per chiarirmi le idee non solo su Predicate.

Tornando all'esercizio devo stampare la lista delle città di mare. Questo è il codice:

public static void main(String args[]) {
...
        System.out.println("Lista città di mare:\n"+ getCittaFiltrate(listaCitta, TestCitta::mare) + "\n");
}    

public static List<Citta> getCittaFiltrate(List<Citta> listaCitta, Predicate<Citta> p) {
        final Iterator<Citta> i = listaCitta.iterator();
        while(i.hasNext()) {            
            Citta citta = i.next();
            if(!p.test(citta)) {
                i.remove();
            }
        }
        return listaCitta;
}
    
public static boolean mare(Citta citta) {
        return "true".equals(citta.isDiMare());
}

Il problema è che stampa sempre una lista vuota perchè anche nel momento in cui va a selezionare una città di mare (es. Bari e Venezia) non riconosce "true" ma "false" e quindi viene lanciato remove() che rimuove l'elemento selezionato dall'iteratore.
Non vorrei che sia un altro errore stupido che non riesco a correggere.

[andbin]

public static boolean mare(Citta citta) {
        return "true".equals(citta.isDiMare());
}

Non vorrei che sia un altro errore stupido che non riesco a correggere.

Ehm ... purtroppo sì, invece. "true" è un String è il equals è il suo, di String. Ma stai passando come argomento un Boolean (autoboxato da boolean). Il equals riceve in generale un Object ma è tipico per le classi verificare che l'oggetto sia dello stesso tipo (tipicamente con instanceof). E String quindi non accetta un Boolean!

Banalmente si potrebbe fare

return citta.isDiMare() == true;

o ancora più semplice:

return citta.isDiMare();

che non cambia nulla nel significato.


Ma c'è di più. Tu hai creato un metodo statico che riceve un Citta e su quest'ultimo invochi un metodo di istanza isDiMare(). Di per sé non servirebbe ... bastarebbe invocare

System.out.println("Lista città di mare:\n"+ getCittaFiltrate(listaCitta, Citta::isDiMare) + "\n");

[newutente]

Ehm ... purtroppo sì, invece. "true" è un String è il equals è il suo, di String. Ma stai passando come argomento un Boolean (autoboxato da boolean). Il equals riceve in generale un Object ma è tipico per le classi verificare che l'oggetto sia dello stesso tipo (tipicamente con instanceof). E String quindi non accetta un Boolean!

Banalmente si potrebbe fare

return citta.isDiMare() == true;

o ancora più semplice:

return citta.isDiMare();

che non cambia nulla nel significato.

accidenti che errore. grazie per avermelo fatto notare.

Ma c'è di più. Tu hai creato un metodo statico che riceve un Citta e su quest'ultimo invochi un metodo di istanza isDiMare(). Di per sé non servirebbe ... bastarebbe invocare

System.out.println("Lista città di mare:\n"+ getCittaFiltrate(listaCitta, Citta::isDiMare) + "\n");

e questo posso farlo perchè il metodo isDiMare restituisce un boolean e quindi è "compatibile" con Predicate?

[andbin]

e questo posso farlo perchè il metodo isDiMare restituisce un boolean e quindi è "compatibile" con Predicate?

Per i metodi (non conto ora la forma per i costruttori) i method reference possono avere in generale tre forme:

object::instanceMethod
Class::staticMethod
Class::instanceMethod

I primi due casi sono equivalenti ad avere una lambda expression che ha tanti parametri quanti sono quelli del metodo.
Es.

Math::max è equivalente ad una lambda expression (a, b) -> Math.max(a, b)

Perché il metodo max ha due parametri (ci sono 4 versioni in overload, con tipi differenti ... quale verrebbe scelto dipende ovviamente dal contesto e dalla inferenza dei tipi).

Mentre il terzo caso è equivalente ad una lambda expression in cui il primo parametro è il "target" del metodo referenziato.
Es.

Citta::isDiMare è equivalente alla lambda expression (c) -> c.isDiMare()

E quest'ultima corrisponde al boolean test(Citta) di Predicate<Citta> perché riceve un parametro (Citta per inferenza) e l'espressione c.isDiMare() dà un boolean.