Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?
Ciao a tutti,
@Federico ("Anche voi siete abituati a fare così quando dovete passare dati
da una DTO a un altro? Se no, come fate?")
Dipende :-)
Nel codice di produzione sì, lo uso spesso, anche perché negli ultimi
progetti che ho realizzato avevo la necessità di creare classi
serializzabili per chiamate RPC con GWT; perciò ho utilizzato la libreria
FreeBuilder (https://github.com/google/FreeBuilder), che permette la
generazione automatica di un builder attraverso annotation e dichiarazione
di metodi abstract; questo riduce notevolmente il boilerplate code ed evita
errori.
Nel codice di test invece generalmente no: uso le API di Mockito per
definire i collaboratori della classe in test o i parametri dei vari
metodi; quindi, il tuo esempio lo scriverei così:
Expense expense = mock(Expense.class);
when(expense.getId()).thenReturn(id);
.
Ma è più una questione di abitudine... alla fine il risultato è lo stesso,
sempre considerando che il builder arriva praticamente a costo zero.
@Tatiana ("In quali occasioni ricorrete al mapping dei bean (trasformazione
di un bean in un altro bean di struttura molto simile se non uguale)?
Quando secondo voi è giustificata la creazione di questi bean differenti e
quando invece è insensato? Preferite mapper automatici tipo dozer o fate a
mano (al di là di come e dove, comunque a mano)?")
Questa domanda e le risposte che ho letto nel thread sono molto
interessanti: ci sono diversi punti di vista, chi è più pragmatico e
minimizza la creazione di strutture nuove e chi invece è più pedissequo
nell'applicare le best practice.
Io appartengo più all'ultima categoria: generalmente creo una nuova classe
quando uno di questi criteri è soddisfatto:
1. c'è un cambio di layer e la classe originale non è immutabile (es. dal
modello del dominio a quello relazionale, sempre se non si utilizza JPA o
un ORM; oppure dal modello del dominio a quello di presentazione)
2. la classe originale è immutabile ma non è serializzabile (caso raro)
3. la classe originale o quella di destinazione appartengono a sistemi
diversi (cfr. port e adapter citato da qualcun altro nel thread)
Per la trasformazione da una classe a un'altra non utilizzo alcun mapper o
framework, solo TDD. È un lavoro un po' tedioso, l'ho fatto proprio in
questi giorni :-/
Ultima cosa: in molti commenti ho visto che il punto è "scrivere troppo";
non credo che questo sia un problema: gli IDE che usiamo sono molto
avanzati, ci sono molte agevolazioni per noi sviluppatori che ci aiutano a
scrivere il nostro codice; è vero che linguaggi creati successivamente a
Java hanno un approccio meno verbose, ma dal mio punto di vista è molto più
importante l'organizzazione dei metodi nelle classi e delle classi nei
package, ovviamente con tutti gli unit test del caso.
Ciao,
Ramon
Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?
Ciao Federico, l'organizzazione del codice e gli unit test aiutano a fare emergere quella che tu chiami "informazione utile": *"*quando generi 1.000 getter al giorno, poi non vedi nel tuo codice quel getter che fa una cosa un po' diversa. Se generi i tuoi equals e poi devi trattare un campo diversamente e' una cosa che non vedi ad occhio*" *=> p erché mai un DTO dovrebbe avere un getter che fa una cosa diversa dagli altri? La responsabilità di di un DTO è trasportare dati, senza comportamenti aggiuntivi. Hai bisogno di applicare una funzione su uno o più di essi? Allora crea le componenti che hanno questa responsabilità al di fuori del DTO, così è tutto più chiaro. *"Poi si, per fortuna l'IDE genera quell'informazione, ma gia' il fatto che ci sia dell'informazione da generare mi farebbe pensare che stiamo lavorando a un livello d'astrazione troppo basso." *=> più che altro l'IDE ti aiuta nella creazione di strutture tutte uguali che, se scritte da un umano, sono soggette ad errori (per non parlare poi della perdita di tempo e della poca voglia che si ha di farlo). Non vedo differenza tra "definire n campi private e fare genere getter e setter dall'IDE" e "una data class in Kotlin": la generazione del codice c'è sempre, anche se nel secondo caso è implicita. Forse il fatto che non siamo distratti da get e set nel sorgente ma vediamo subito gli altri metodi? Allora ricadiamo nel punto precedente. Spero di avere colto quello che intendevi dire, ciao ;-) Ramon
Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?
*"Il fatto e' che non vedo informazione ridondante per cui noto tutti i casi "particolari"...* > *Si, capisco l'intento, ma i casi particolari non li voglio in un oggetto "da trasporto". Per quello preferisco una bella classe con tutti campi public-static-final + costruttore, o l'approccio di Federico (niente del tutto)."* È quello che avevo detto qualche messaggio fa: un DTO non ha comportamenti. Pero, Bruno, se mi consenti una considerazione... public static final nei campi va bene fino ad un certo punto, con oggetti mutabili credo che si lasci la porta aperta a disastri. Ciao, Ramon
Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?
*"* > > *[...] se mi consenti una considerazione public final nei campi va > bene fino ad un certo punto,* > *con oggetti mutabili credo che si lasci la porta aperta a disastri* *Scusa, c'e' uno "static" di troppo. Sono public final e, pertanto, non mutabili. L'unico modo per "caricarli" e' con il costruttore* *Ciao,* *Bruno"* La sostanza non cambia: se uno dei field esposto come public final è mutabile (es. java.util.Date o una qualsiasi Collection) allora la classe che crei non è immutabile ed è possibile che un client che la usa possa invalidare gli invarianti che sono stati definiti; molto meglio proteggere l'informazione a mio avviso (se vuoi ti faccio un esempio). Siamo andati un po' OT comunque... :-) Ho visto le mappe che ha indicato Federico e non fanno al caso mio: dall'esempio che ho visto su GitHub mi sembra che si perdano tutti i benefici di avere un compilatore e un linguaggio tipizzato solo per evitare di scrivere setter e getter; ci sono altri modi IMHO. Ciao, Ramon
Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?
*"eh eh non ho bisogno di un esempio, grazie :), la tua osservazione e' corretta ovviamente, e va tenuta in conto anche usando lombok o i getter, e come sicuramente sai, in tutti i casi di logica concorrente. Pero', appunto, i miei oggetti da "trasporto" sono molto stupidi e, nel caso sia richiesto, mi proteggo nel costruttore creando versioni immutabili. Se ti trovi a fare cose complicate, lo stai facendo sbagliato :)* *In generale, comunque, devo ammettere che che raramente la mutabilita di questo tipo di oggetti è per me rilevante: appena uno di essi mi entra nella zona "OO" viene immediatamente assimilato e dimenticato.* *A riguardo della tua osservazione sui tipi ricorda che questi oggetti "tristi" (o quelli "ignoranti" di Fede) si usano solo quando hai un paradigm shift, raramente i tipi hanno rilevanza. Caso classico un API REST che riceve una chiamata in formato misto json/xml/whatever: il massimo dell'astrazione sono mappe/array/stringhe.* *Direi che siamo pienamente in topic comunque :)* *Ciao,* *Bruno"* Ok, con queste ipotesi allora tutto torna, anche la parte sull'uso delle mappe di Federico se utilizzata solo nel caso che hai citato, probabilmente mi ero perso qualche info nei vari messaggi del thread ;-) Ciao, Ramon
