Ciao a tutti,
non ho letto tutti i posts quindi potrei ripetere il tema.
Nel riversamento da un bean a un altro, l'ho fatto con metodi automatici
alla dozer, che però mi è parso rigido, e poi a mano.
Quando l'ho realizzato a mano ho trovato sempre un problema ricorrente
fastidioso, quello ad esempio del tipo
obj1.setCampo(obj2.getCampo1().getCampo2()
..getCampo3.getCampo4()....)
e doverci fare il controllo dei null. allora, con java8 avevo pensato di
trasformare tutto in un supplier con l'ultimo get così ::getn
e infilarlo in un metodo di utility tipo checkNull ma fatto in scala dove
il parametro è del tipo
checkNull(supplier : => Supplier[t]) {
T result = null;
try {
result = supplier.get();
} catch (NullPointerException e) {
result = null;
}
result;
}
Ora personatemi la sintassi in Scala perchè è da un po' che non lo uso
però, essendo il parametro supplier con => valutato solo al momento in cui
viene usato, potrebbe funzionare? Non ho avuto il tempo di realizzarlo
praticamente, benchè semplice.
In java il parametro lo calcolerebbe, benchè sia cmq una funzione, prima di
entrare nel metodo, e lasciare non calcolato l'ultimo pezzo che crea il
supplier, cioè il ::getn.
Che ne pensate. Non parlatemi degli Optional in java perchè mi pare troppo
verbosa come soluzione. Meglio allora gli if semplici a blocchi nella lista
si set e get del metodo di riversamento.
Ciao, Angelo
Il giorno 18 gennaio 2018 21:16, Roberto Franchini ro.franch...@gmail.com
[it-torino-java-jug] <it-torino-java-jug@yahoogroups.com> ha scritto:
>
>
>
>
> 2018-01-18 19:44 GMT+01:00 Tatiana Litvinova tatiana.litvin...@gmail.com
> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>
>>
>>
>> Ciao Federico,
>>
>> Riguardo l'approccio con la mappa, mi sembra un modo di aggirare il
>>> problema di stare usando Java. Quest'approccio mi fa tornare in mente un
>>> articolo di Martin Fowler che diceva che comunque tu hai sempre uno schema
>>> dei dati, che sia implicito ed esplicito (forse era qui:
>>> https://martinfowler.com/articles/schemaless). Questo perche'
>>> l'utilizzatore andra' a leggersi certi campi, avra' certe aspettative. Per
>>> cui mi conforta avere lo schema esplicito, sotto forma di classe. D'altra
>>> parte se ti scrivi gli opportuni test lo schema lo vai invece a
>>> "cristallizzare" nei test. L'approccio a classi, oltre all'aiuto del
>>> compilatore mi darebbe la possibilita' di usare la reflection dove serve.
>>>
>>
>> Grazie, molto bello l'articolo.
>>
>> Però sostanzialmente conferma la mia reticenza ad usare le mappe: nel
>> nostro caso il problema non è tanto il fatto di non conoscere a priori la
>> struttura dati e non è il fatto che la struttura non sia uniforme (due dei
>> tre trigger che utilizza per scegliere che tipo di schema utilizzare). Il
>> problema è il numero di trasformazioni inutili che facciamo in rapporto al
>> numero di quelle realmente utili.
>>
>>
> Si', le orogini della nostra scelta passata si basavano proprio sul fatto
> che non sapevamo mai da dove ed in che formato sarebbero arrivati i
> prossimi dati e dove e come li avremmo esportati/visualizzati.
>
>
> [cut]
>
>
>> Mi togliete una curiosità dovuta alla mia ignoranza: perché proprio
>> Kotlin? Mi sarei aspettata di vedere citati diversi linguaggi la cui
>> sintassi facilita lo sviluppo, invece c'è il coro unanime pro-Kotlin. Come
>> mai?
>>
>>
> Ci sono svariati motivi:
> - e' tipato e compilato
> - e' veramente interoperabile con Java: da kotlin usi java e da java usi
> kotlin
> - i progetti multilinguaggio FUNZIONANO.
> - e' un linguaggio moderno, pulito, senza tutto il boilerplate di java
> - e' abbastanza funzionale
> - e' ad oggetti
> - la curva di apprendimento e' piatta
> - l'ide ti aiuta un sacco (copia codice java in file kotlin, te lo
> converte :) )
>
>
> sto andando per gradi, ora ho il primo codice in produzione in Kotlin
> dentro ad un progetto Java ed una piccola libreria full kotlin.
> full kotlin vuol dire che anche il file di build di gradle e' scritto in
> kotlin.
> Per il progetto misto, ho aggiunto 4 righe in gradle, ha funzionato tutto..
> Quando avro' un intero progetto scritto con un solo linguaggio,dalla build
> al frontend, e quel linguaggio non sara' JS, daro' una festa.
> FRANK
>
>
> --
> Roberto Franchini
> "The impossible is inevitable"
> https://github.com/robfrank/
> https://twitter.com/robfrankie
> https://www.linkedin.com/in/robfrank
>
>
>
