Grazie Bruno e grazie a tutti per gli spunti. Facendo retrospettiva, per me devono verificarsi queste due condizioni ( > *entrambe*): [8<] >
Direi molto chiaro come trigger. Ma... E poi YAGNI, se posso lo evito. Ho sempre tempo a rifattorizzare dopo. > Invece qui un po' meno. 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 "viste" json per tutti gli oggetti che vengono serializzati? E per le Entity (ammesso che le usi)? > > - ormai faccio solo piu' microservizi (alla faccia di quelli che mi > prendevano per il culo nel 2013 :)) quindi se vuoi la mia architettura > internamente e' generalmente molto semplice > > Questo sarebbe un altro argomento interessante da affrontare, magari in un thread a parte. Per quanto riguarda invece la verbosità di Java (lamentata implicitamente anche da Federico, mi pare), il problema c'è ma non so se è *il* problema. L'interfaccia fluente con dei nomi dei metodi corti è più carina e più trendy, ma fa davvero tanta differenza nella sostanza? Le mappe... capisco i pro, ma l'assenza di un controllo sintattico sulle chiavi mi fa paura. E il refactoring? @Andrea: per curiosità, posso chiederti un esempio in Kotlin? Ciao, Tatiana > >
