Cosi' e' e non c'e' molto da fare, ma in realta' il mio caso d'uso funzionava benissimo con le static inner class.
Avevo definito gli oggetti immutabili di dominio come interfacce in un bundle (modulo) shared, ogni bundle che doveva crearne una istanza (per esempio il DAO e il modulo che riceveva json) non faceva altro che creare una anonymous class di quella interfaccia e restituirla. In questo modo mi evitavo di sherare la classe o di dover avere l'interfaccia implementata in diversi moduli. Essendo passato a kotlin non ho piu' il problema e con Valhalla sparira' anche in Java. Uberto On Mon, 3 Dec 2018 at 08:38, Matteo Vaccari [email protected] [it-torino-java-jug] <[email protected]> wrote: > > > Credo che sia utile immaginare le inner class anonime come delle closure. > > Nel tuo esempio: restituisci un'istanza di un'inner class anonima, ed e' > una buona cosa che in quella inner class tu possa accedere alle variabili > della classe dentro a cui la costruisci; altrimenti l'utilita' di poter > costruire una inner class anonima al volo e' limitata. > > On Sun, Dec 2, 2018 at 11:11 PM Uberto Barbini [email protected] > <[email protected]> [it-torino-java-jug] < > [email protected]> wrote: > >> >> >> Ciao Federico e grazie per le interessanti osservazioni. >> >> Sinceramente a me non interessa moltissimo il "trucco" delle tuple >> anonime, carino ma insomma non lo userei in produzione, leak o non leak. >> >> Il pattern del doppio curlybraces poi non l'ho mai potuto soffrire. >> >> La cosa che invece mi ha un po' preoccupato e' l'idea che implementando >> una interfaccia al volo mando in giro un riferimento all'istanza della >> classe che l'ha creata. >> >> Per dire codice tipo questo: >> https://gist.github.com/uberto/c37970ba1d3b49c61568809085a84d1f >> >> Ecco codice cosi' io l'ho scritto in produzione e non avevo idea che >> stavo mandando in giro un riferimento alla classe creatrice. >> >> Per curiosita' ho provato con un metodo statico e in questo caso la >> classe anonima creata non ha un riferimento alla factory. Penso sia una >> static inner class ma non so se c'e' un modo sicuro per dirlo. >> >> Uberto >> >> >> >> >> >> >> >> On Sun, 2 Dec 2018 at 11:28, Federico Fissore [email protected] >> [it-torino-java-jug] <[email protected]> wrote: >> >>> >>> >>> Matteo Vaccari [email protected] [it-torino-java-jug] ha scritto >>> il 01/12/18 alle 19:42: >>> > >>> > Non e' ovvio! Grazie per avermelo ricordato. >>> > >>> >>> Prego e grazie per il grazie. Come dice il saggio, è l'unica parola che >>> non perde mai valore, anche detta migliaia di volte. >>> >>> Mi scuso se ho dato per scontato che parlavo di istanze di classi e non >>> solo di classi >>> >>> Uberto Barbini [email protected] [it-torino-java-jug] ha scritto il >>> 02/12/18 alle 11:24: >>> > >>> > credo che se le fai generare da un metodo statico sei tranquillo, ma >>> > vorrei fare dei tests più approfonditi... >>> > >>> >>> Bella domanda >>> >>> Ho provato a modificare lo snippet condiviso prima: se dichiari static >>> il metodo Filter3.filter, il compilatore va in errore alla riga "return >>> Filter3.this.sayHi()". Che ha senso: se la inner class viene usata in un >>> metodo statico, non c'è istanza a cui fare riferimento >>> >>> Allora ho fatto un'altra prova usando questo snippet >>> >>> https://gist.github.com/ffissore/f410842f6e83e31c326889155e5162b6 >>> >>> e ho scoperto una cosa che non sapevo: fra i "campi nascosti" che ti >>> becchi con una inner class c'è anche la "v" (String) usata nel metodo >>> map dello stream (accessibile con it.jugtorino.Filter4$1.val$v). Che di >>> nuovo non è banale, se l'intenzione del programmatore era destrutturare >>> un oggetto ricco e complesso, per fornire al chiamate solo quelle "2 >>> cose che gli servono" >>> >>> federico >>> >> >
