Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] ha scritto il 16/01/2018 alle 22:28: > è *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

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-16 22:28 GMT+01:00 Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] : > > > Grazie Bruno e grazie a tutti per gli spunti. > > >> @Andrea: per curiosità, posso chiederti un esempio in Kotlin? > > Una data class in Kotlin data class

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

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

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

Eh sarebbe bello se il TDD rendesse impopolari i singleton :) In realtà si', li rende impopolari ma solo per i pochissimi che fanno veramente TDD! 2018-01-15 22:58 GMT+01:00 Massimo Ugues m.ug...@gmail.com [it-torino-java-jug] : > > > *L'uso dei builder per

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] ha scritto il 15/01/2018 alle 22:47: > con un servizio esterno al sistema ecc.), ma in molti casi la logica > vera poi non è molta, ed il sistema si limita per la maggior parte a > trasformare. > per questo motivo (e altri)