Ciao a tutti,
ho trovato molto interessante questa discussione.
I due approcci che preferirei sono quello della mappa e l'uso di Kotlin.
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
>
> Mettiamo il caso che tu abbia iniziato a sviluppare senza creare gli
> oggetti "vista"...
>
Questo e' il default per me.
> ...ad un certo punto ti sei accorto che *per un caso particolare* invece
> era indispensabile. Che cosa fai:
> 1. crei una "vista" solo per quell'oggetto e gli altri co
ср, 17 янв. 2018 г. в 14:29, bruno bossola bboss...@gmail.com
[it-torino-java-jug] :
> Stai dicendo che parti senza la duplicazione degli oggetti finché non
>> trovi un caso per cui si verificano entrambe le condizioni (es. il primo
>> oggetto che non riesci a serializzare in json). A quel punto c
ср, 17 янв. 2018 г. в 11:04, Andrea Cerisara andreaceris...@gmail.com
[it-torino-java-jug] :
>
>
> Ciao Tatiana,
>
Ciao Andrea!
imho é il problema perché riscrivendo quel modulo in Kotlin abbiamo smesso
> di fare discussioni come questa.
>
Può essere, forse bisognerebbe provare per credere, per
ср, 17 янв. 2018 г. в 8:45, Roberto Franchini ro.franch...@gmail.com
[it-torino-java-jug] :
> Ci sono un paio di talk, uno suo ed uno mio, un po' datati, tra i video
> del JUG, mi pare il titolo sia Kill Bean 1 e 2
>
Appena riesco a trovare tempo sufficiente provo a cercare invece di
tempestarvi
Ciao a tutti,
ricordo che stasera si terra' il nostro consueto meeting:
Potete ancora iscrivervi:
https://www.meetup.com/JUGTorino/events/246048923/
--
Roberto Franchini
"The impossible is inevitable"
https://github.com/robfrank/
https://twitter.com/robfrankie
https://www.linkedin.com/in/robfr
>
> Stai dicendo che parti senza la duplicazione degli oggetti finché non
> trovi un caso per cui si verificano entrambe le condizioni (es. il primo
> oggetto che non riesci a serializzare in json). A quel punto cosa fai? Crei
> una "vista" soltanto per quell'oggetto? Rifattorizzi, introducendo le
Ciao Tatiana,
imho é il problema perché riscrivendo quel modulo in Kotlin abbiamo smesso
di fare discussioni come questa.
Diciamo che architetturalmente ci piace avere un bean apposito ogni qual
volta saltiamo da un layer all' altro (quindi strategia `sempre e comunque`
perché é consistente e ci