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

[max carbone max.carb...@gmail.com [it-torino-java-jug]]

>
>
>> Command-Query Responsibility Segregation
>>
>
> Mi sento a casa :) Noi lo usiamo in combinazione con Event Sourcing (Axon
> nell specifico come implementazione).
>

​Ignorante che sono, ho "scoperto" il pattern CQRS solo di recente, anch'io
combinato al pattern Event Sourcing (ref.:
http://microservices.io/patterns/data/cqrs.html ).

Bye.  max


-- 
'Electric lamps were not invented by improving candles'

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

[Andrea Cerisara andreaceris...@gmail.com [it-torino-java-jug]]

2018-01-27 19:35 GMT+11:00 Matteo Vaccari matteo.vacc...@gmail.com
[it-torino-java-jug] :

>
>
> Si chiama Command-Query Responsibility Segregation, l'ho imparata da
> Alberto Brandolini.
>

>

Mi sento a casa :) Noi lo usiamo in combinazione con Event Sourcing (Axon
nell specifico come implementazione).

-- 
** Think about the environment before printing

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

[Ivan Martoccia m.iv...@gmail.com [it-torino-java-jug]]

Non vorrei dire ma... ho trovato anche questa roba in giro per il "mondo"..
Si salvi chi può..
Andare di reflection a runtime ( e chissà quante volte ) non pensate sia un
pelo eccessivo?

public static void copiaOggetto(Object oggettoDaCopiare, Object
oggettoNuovo) {
Class classOggettoDaCopiare = oggettoDaCopiare.getClass();
Class classOggettoNuovo = oggettoNuovo.getClass();
Field[] arrField=classOggettoDaCopiare.getDeclaredFields();
log.info("Inizio Copying da "+classOggettoDaCopiare.getName()+ " a
"+classOggettoNuovo.getName());
for(Field campoOggettoDaCopiare:arrField) {
if((campoOggettoDaCopiare.getType().getName().contains("java.lang")
|| campoOggettoDaCopiare.getType().getDeclaredFields().length==0
|| campoOggettoDaCopiare.getType().getName().contains("java.util.Date") )
&& !campoOggettoDaCopiare.getType().getName().contains("java.util.List")){
Field campoOggettoNuovo=null;
try {
campoOggettoNuovo =
classOggettoNuovo.getDeclaredField(campoOggettoDaCopiare.getName());
} catch (NoSuchFieldException e) {
System.out.println("campo "+campoOggettoDaCopiare.getName()+ " non
trovato");
continue;
} catch (SecurityException e) {
System.out.println("campo "+campoOggettoDaCopiare.getName()+ " non
trovato");
continue;
}
Field fieldFrom =null;
try {
fieldFrom =
oggettoDaCopiare.getClass().getDeclaredField(campoOggettoDaCopiare.getName());
} catch (NoSuchFieldException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
} catch (SecurityException e1) {
// TODO Auto-generated catch block
e1.printStackTrace();
}
Object valoreDaCopiare =null;
try {
fieldFrom.setAccessible(true);
valoreDaCopiare = fieldFrom.get(oggettoDaCopiare);
} catch (IllegalArgumentException e) {
System.out.println(campoOggettoDaCopiare.getName()+" errore in getvalore
non trovato");
continue;
} catch (IllegalAccessException e) {
System.out.println(campoOggettoDaCopiare.getName()+" errore in getvalore
non trovato");
continue;
}
try {
if(valoreDaCopiare!=null) {
campoOggettoNuovo.setAccessible(true);
campoOggettoNuovo.set(oggettoNuovo, valoreDaCopiare);
}
} catch (IllegalArgumentException e) {
System.out.println(campoOggettoDaCopiare.getName()+" errore in set valore
trovato");
continue;
} catch (IllegalAccessException e) {
System.out.println(campoOggettoDaCopiare.getName()+" errore in set valore
trovato");
continue;
}
}
}
log.info("Fine Copying da "+classOggettoDaCopiare.getName()+ " a
"+classOggettoNuovo.getName());
}





Il giorno 25 gennaio 2018 05:56, Andrea Cerisara andreaceris...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Ciao,
>
> 2018-01-22 9:29 GMT+11:00 Ramon Flamia ramon.fla...@gmail.com
> [it-torino-java-jug] :
>
>>
>>
>> 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.
>>
>
> noi ci rompiamo anche a ripetere sempre gli stessi shortcuts di IntelliJ
> quando potremmo farne a meno :)
>
> Anche io sono d' accordo sull' organizzazione del codice, e preferisco
> Kotlin anche in questo caso. Ha un approccio piu' flessibile, simil Python
> per intenderci. Restando al caso dei DTO, essendo dichiarazioni molto
> leggere, o li mettiamo nello stesso file dei controller, oppure li
> raggruppiamo tutti in un solo file, con eventuali funzioni di supporto per
> la trasformazione. Non vogliamo in questo caso avere un file separato per
> DTO, mentre tendiamo a tenere la convenzione in Java quando definiamo i
> controller invece. Ma il punto importante secondo me e' che abbiamo la
> flessibilita' e la possibilita' di scelta.
>
> --
> ** Think about the environment before printing
>
> 
>



-- 
Response to : m.iv...@gmail.com

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

[bruno bossola bboss...@gmail.com [it-torino-java-jug]]

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

On 23 Jan 2018 19:07, "Ramon Flamia ramon.fla...@gmail.com
[it-torino-java-jug]"  wrote:

>
>
> *"*
>>
>> *[...] 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?

[Ramon Flamia ramon.fla...@gmail.com [it-torino-java-jug]]

*"*
>
> *[...] 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?

[Andrea Cerisara andreaceris...@gmail.com [it-torino-java-jug]]

2018-01-19 12:55 GMT+01:00 axa1...@gmail.com [it-torino-java-jug] <
it-torino-java-jug@yahoogroups.com>:

>
>
> Ciao Ciri! :D
>
Mi-iii-cco! :)


>
> Grazie a tutti perché questa discussione é sicuramente molto stimolante
> per tutti.
>
> Ecco purtroppo la questione supporto e penetrazione enterprise non è da
> poco. Come sappiamo la superiotità tecnica da sola non basta (ehm...
> Scala?),
>

Mah oddio, io sono scappato a gambe levate da Scala dopo quattro mesi :)


> ma ci sono indizi che Oltre che da Google Kotlin possa essere supportato
> anche da altri big dell’industria? Un endorsment da parte di Oracle
> potrebbe cambiare completamente la situazione.
>

Oracle? Ma speriamo! :)


> Magari qualcuno che si compri JetBrains? Kotil per ora resta solo giudato
> da loro o no?
>

> Paolo
>

-- 
** Think about the environment before printing

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

[axa1...@gmail.com [it-torino-java-jug]]

Ciao Ciri! :D 

 Grazie a tutti perché questa discussione é sicuramente molto stimolante per 
tutti.
 

 Ecco purtroppo la questione supporto e penetrazione enterprise non è da poco. 
Come sappiamo la superiotità tecnica da sola non basta (ehm... Scala?), ma ci 
sono indizi che Oltre che da Google Kotlin possa essere supportato anche da 
altri big dell’industria? Un endorsment da parte di Oracle potrebbe cambiare 
completamente la situazione.
 

 Magari qualcuno che si compri JetBrains? Kotil per ora resta solo giudato da 
loro o no?
 

 Paolo

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

[Roberto Franchini ro.franch...@gmail.com [it-torino-java-jug]]

2018-01-18 19:44 GMT+01:00 Tatiana Litvinova tatiana.litvin...@gmail.com
[it-torino-java-jug] :

>
>
> 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

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

[bruno bossola bboss...@gmail.com [it-torino-java-jug]]

>
> 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 continui a
> serializzare/deserializzare gli oggetti di dominio?
> 2. oppure, per uniformità, rifattorizzi tutto il codice introducendo le
> "viste" per tutti gli oggetti che vengono "visti" in json (spero di no!)?
> 3. oppure c'è un'altra opzione che non mi è venuta in mente?
>

La 1


I metodi from/to li uso anch'io (chissà come mai?).


Bene ma se ci metti altri metodi oltre a quelli, non benissimo :) Il trucco
e' farli veramente tristi. Nota che c'era un refuso nel mio precedente
codice:

public class UserZero {

*public* final UUID uuid;
*public* final String name;

public UserZero(User user) {
this.uuid = user.uuid();
this.name = user.name());
}

public User create(UserRepository users, Magic magic) {
  ...
   }
}

Nota gli attributi pubblici eh :) Il trucco e' che una volta costruito
l'oggetto, diventano immutabili, quindi non c'e' problema ad usarli belli
diretti. Altrimenti Lombok. Comunque non mi spaventa l'approccio del
Fissore, mi sa che lo provo pure io... meno codice, meglio e'!


Eppure mi hai torturata con un librone enorme sugli EJB2 prima
> dell'assunzione :D..
> Non ti ho mai detto quanto mi aveva fatto schifo?


Eh non ero io che dettavo le regole, erano la tua amica al CSI... Gemma, se
mi ricordo bene? Dopo aver accettato l'offerta con scritto "zero EJB" ce li
hanno rificcati dentro...

Ciao,

 Bruno





2018-01-17 20:38 GMT+00:00 Tatiana Litvinova tatiana.litvin...@gmail.com
[it-torino-java-jug] :

>
>
> ср, 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 cosa fai? Crei
>>> una "vista" soltanto per quell'oggetto? Rifattorizzi, introducendo le
>>> "viste" json per tutti gli oggetti che vengono serializzati?
>>
>>
>> Di solito genero un value object con dei metodi from/to rispetto al mio
>> oggetto vero (i.e. un costruttore che crea in base all'oggetto vero, una
>> factory the ritorna l'oggetto vero a cui passo extras).
>>
>
> Mi sono spiegata male Bruno, la mia domanda era un'altra. Provo a
> riformularla.
> Mettiamo il caso che tu abbia iniziato a sviluppare senza creare gli
> oggetti "vista" perché non ti servivano, riuscivi a
> serializzare/deserializzare anche senza. 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 continui a
>serializzare/deserializzare gli oggetti di dominio?
>2. oppure, per uniformità, rifattorizzi tutto il codice introducendo
>le "viste" per tutti gli oggetti che vengono "visti" in json (spero di 
> no!)?
>3. oppure c'è un'altra opzione che non mi è venuta in mente?
>
> I metodi from/to li uso anch'io (chissà come mai?).
>
>
>> E posso anche dire: *mai usato EJB in vita mia!!! *
>>
>
> Eppure mi hai torturata con un librone enorme sugli EJB2 prima
> dell'assunzione :D..
> Non ti ho mai detto quanto mi aveva fatto schifo?
>
> Ciao,
> Tatiana
>
>> 
>

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

[Federico Fissore feder...@fsfe.org [it-torino-java-jug]]

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 un controllo sintattico sulle 
> chiavi mi fa paura. E il refactoring?
> 

Capisco e condivido la preoccupazione. Ma ai tempi pensai: in javascript 
faccio già così e lo so fare, in java può solo essere più facile.
E lo confermo: quasi all'improvviso ti trovi senza annotazioni, senza 
librerie di mapping, senza boilerplate. Solo ciccia. Codice più breve, 
più facile da testare.

federico

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

[Roberto Franchini ro.franch...@gmail.com [it-torino-java-jug]]

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 Person(val name: String, val surname: String, val age: Int, val
nickname: String? = null)

se vuoi aggiungere un metodo:

data class Person(val name: String, val surname: String, val age: Int, val
nickname: String? = null) {

fun isAdult(): Boolean {

return age > 18
}
}


una lista di persone:

val frank = Person("rob", "frank", 44)

val persons = listOf(frank, Person("simon", "bor", 25),
Person("fred", "fix", 16, "lumberjack"))

nota il parametro nickname, definito come nullable e quindi facoltativo.
Puoi anche avere valori di default
Per stampare i nomi:

for ((i, person) in persons.withIndex()) {

println("person= ${person.name} at index $i")

}


person.name puoi anche scrigere person.getName()
Se usi la data class da Java, userai person.getName()

FRANK
-- 
Roberto Franchini
"The impossible is inevitable"
https://github.com/robfrank/
https://twitter.com/robfrankie
https://www.linkedin.com/in/robfrank

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

[Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug]]

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

> 
>

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

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

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 costruire oggetti nei test è stato reso popolare
> dal GOOS *
>
> Sinceramente non riesco a vedere una differenza sostanziale tra un builder
> e una fluent interface dei setter del POJO in oggetto.
> Come PRO la fluent interface ti evita di avere una classe che fa appunto
> da builder, e come spesso LESS IS MORE.
>
> Il fatto che tu sostenga che i builder siano stati resi popolari dal TDD
> mi sembra a dir poco opinabile (https://tinyurl.com/y9qxgzhh).
> E' un po' come dire che il Singleton sia stato reso impopolare dallo
> stesso movimento..
>
>
>
> 2018-01-15 21:30 GMT+01:00 Matteo Vaccari matteo.vacc...@gmail.com
> [it-torino-java-jug] :
>
>>
>>
>>
>> L'uso dei builder per costruire oggetti nei test è stato reso popolare
>> dal GOOS 
>>
>> 2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org
>> [it-torino-java-jug] :
>>
>>>
>>>
>>> Ciao
>>>
>>> domandina del venerdì sera
>>>
>>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>>
>>> return ExpenseBuilder.anExpense()
>>> .withId(id)
>>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>>> .withDate(new Date())
>>> .withReason("Something pretty")
>>> .build();
>>>
>>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>>> presi da un altro bean via getter, oppure quest altro bean offre lui un
>>> metodo che restituisce un builder pre-popolato
>>>
>>> Anche voi siete abituati a fare così quando dovete passare dati da una
>>> DTO a un altro? Se no, come fate?
>>>
>>> ciao
>>>
>>> federico
>>>
>>
>>
>
>
> --
> Massimo Ugues
>
> 
>

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

[Federico Fissore feder...@fsfe.org [it-torino-java-jug]]

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) avevo smesso di scrivere java bean, in 
favore di mappe con interfaccia fluente e metodi corti (l'ultima che ho 
implementato è https://github.com/ffissore/SteroidMap)

ho evitato di scrivere centinaia di righe di codice e forse di più.
praticamente facevo in java quello che farei in javascript (non tirate 
pomodori, che non è stagione)

"facevo" appunto, perchè invece dove lavoro ora non funziona così

federico

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

[Massimo Ugues m.ug...@gmail.com [it-torino-java-jug]]

*L'uso dei builder per costruire oggetti nei test è stato reso popolare
dal GOOS *

Sinceramente non riesco a vedere una differenza sostanziale tra un builder
e una fluent interface dei setter del POJO in oggetto.
Come PRO la fluent interface ti evita di avere una classe che fa appunto da
builder, e come spesso LESS IS MORE.

Il fatto che tu sostenga che i builder siano stati resi popolari dal TDD mi
sembra a dir poco opinabile (https://tinyurl.com/y9qxgzhh).
E' un po' come dire che il Singleton sia stato reso impopolare dallo stesso
movimento..



2018-01-15 21:30 GMT+01:00 Matteo Vaccari matteo.vacc...@gmail.com
[it-torino-java-jug] :

>
>
>
> L'uso dei builder per costruire oggetti nei test è stato reso popolare dal
> GOOS 
>
> 2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org
> [it-torino-java-jug] :
>
>>
>>
>> Ciao
>>
>> domandina del venerdì sera
>>
>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>
>> return ExpenseBuilder.anExpense()
>> .withId(id)
>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>> .withDate(new Date())
>> .withReason("Something pretty")
>> .build();
>>
>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>> presi da un altro bean via getter, oppure quest altro bean offre lui un
>> metodo che restituisce un builder pre-popolato
>>
>> Anche voi siete abituati a fare così quando dovete passare dati da una
>> DTO a un altro? Se no, come fate?
>>
>> ciao
>>
>> federico
>>
>
> 
>



-- 
Massimo Ugues

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

[Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug]]

In realtà più che esempi volevo capire i criteri che utilizzate per
prendere la decisione di "sdoppiare" il bean e perché.

Ad esempio: creo sempre dei bean specifici per le "viste" sugli oggetti
perché ... / creo un bean specifico per la "vista" di un particolare
oggetto soltanto quando ... perché ... / creo una "duplicazione" dello
stesso bean soltanto sotto tortura perché ...

Personalmente credo che ogni decisione abbia dei pro e dei contro, non
sempre sono evidenti subito. La mia inclinazione è quella di avere degli
oggetti core del sistema (oggetti "veri" come li hai chiamati, con della
logica vera) + una rappresentazione per ogni tipo di boundary (vista da
serializzare/deserializzare, entity per il database, dto per colloquiare
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.

Ciao,
Tatiana

пн, 15 янв. 2018 г. в 18:59, bruno bossola bboss...@gmail.com
[it-torino-java-jug] :

>
>
> Mah, per esempio nei servizi REST raramente serializzo l'oggetto, ma una
> "vista" di esso. Lo stesso in ingresso, ricevo una "vista" e da quella
> ottengo il vero oggetto.
> Questo per me e' l'esempio piu' comune, e faccio a mano, si, li testo di
> solito perche' quando creo l'oggetto "vero" di solito passo parametri
> (magari un repository) e c'e' della logica "vera" da disegnare.
>
> Ciao,
>
> Bruno.
>
> 2018-01-15 17:35 GMT+00:00 Tatiana Litvinova tatiana.litvin...@gmail.com
> [it-torino-java-jug] :
>
> Ciao a tutti,
>>
>> Vorrei allargare la questione posta da Federico.
>>
>> 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)?
>>
>> Grazie,
>> Tatiana
>>
>> вс, 14 янв. 2018 г.. в 11:23, bruno bossola bboss...@gmail.com
>> [it-torino-java-jug] :
>>
>
>>>
>>> Se il problema e' che da A devo costruire B, allora un metodo in A che
>>> si chiama "buildB()": questo per "information expert" (GRASP)
>>> ,
>>>  e
>>> se ci sono cose secondarie da usare nella conversione le passo come
>>> parametro.
>>>
>>> In altri casi dipende... in genere cerco di assegnare la responsabilita'
>>> a qualche oggetto che ha senso che ce l'abbia :)
>>> Ciao,
>>>
>>> Bruno
>>>
>>>
>>> 2018-01-12 17:35 GMT+00:00 Federico Fissore feder...@fsfe.org
>>> [it-torino-java-jug] :
>>>


 Ciao

 domandina del venerdì sera

 Da qualche tempo vedo con crescente frequenza questo tipo di codice

 return ExpenseBuilder.anExpense()
 .withId(id)
 .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
 .withDate(new Date())
 .withReason("Something pretty")
 .build();

 Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
 presi da un altro bean via getter, oppure quest altro bean offre lui un
 metodo che restituisce un builder pre-popolato

 Anche voi siete abituati a fare così quando dovete passare dati da una
 DTO a un altro? Se no, come fate?

 ciao

 federico

>>>
>>> 
>

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

[Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug]]

L'uso dei builder per costruire oggetti nei test è stato reso popolare dal
GOOS 

2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org
[it-torino-java-jug] :

>
>
> Ciao
>
> domandina del venerdì sera
>
> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>
> return ExpenseBuilder.anExpense()
> .withId(id)
> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
> .withDate(new Date())
> .withReason("Something pretty")
> .build();
>
> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
> presi da un altro bean via getter, oppure quest altro bean offre lui un
> metodo che restituisce un builder pre-popolato
>
> Anche voi siete abituati a fare così quando dovete passare dati da una
> DTO a un altro? Se no, come fate?
>
> ciao
>
> federico
> 
>

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

[Ivan Martoccia m.iv...@gmail.com [it-torino-java-jug]]

Io da poco ho scoperto MapStruct ( http://mapstruct.org/ ) che non trovo
affatto male.

Il giorno 15 gennaio 2018 18:59, bruno bossola bboss...@gmail.com
[it-torino-java-jug]  ha scritto:

>
>
> Mah, per esempio nei servizi REST raramente serializzo l'oggetto, ma una
> "vista" di esso. Lo stesso in ingresso, ricevo una "vista" e da quella
> ottengo il vero oggetto.
> Questo per me e' l'esempio piu' comune, e faccio a mano, si, li testo di
> solito perche' quando creo l'oggetto "vero" di solito passo parametri
> (magari un repository) e c'e' della logica "vera" da disegnare.
>
> Ciao,
>
> Bruno.
>
> 2018-01-15 17:35 GMT+00:00 Tatiana Litvinova tatiana.litvin...@gmail.com
> [it-torino-java-jug] :
>
>>
>>
>> Ciao a tutti,
>>
>> Vorrei allargare la questione posta da Federico.
>>
>> 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)?
>>
>> Grazie,
>> Tatiana
>>
>> вс, 14 янв. 2018 г.. в 11:23, bruno bossola bboss...@gmail.com
>> [it-torino-java-jug] :
>>
>>>
>>>
>>> Se il problema e' che da A devo costruire B, allora un metodo in A che
>>> si chiama "buildB()": questo per "information expert" (GRASP)
>>> ,
>>>  e
>>> se ci sono cose secondarie da usare nella conversione le passo come
>>> parametro.
>>>
>>> In altri casi dipende... in genere cerco di assegnare la responsabilita'
>>> a qualche oggetto che ha senso che ce l'abbia :)
>>> Ciao,
>>>
>>> Bruno
>>>
>>>
>>> 2018-01-12 17:35 GMT+00:00 Federico Fissore feder...@fsfe.org
>>> [it-torino-java-jug] :
>>>


 Ciao

 domandina del venerdì sera

 Da qualche tempo vedo con crescente frequenza questo tipo di codice

 return ExpenseBuilder.anExpense()
 .withId(id)
 .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
 .withDate(new Date())
 .withReason("Something pretty")
 .build();

 Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
 presi da un altro bean via getter, oppure quest altro bean offre lui un
 metodo che restituisce un builder pre-popolato

 Anche voi siete abituati a fare così quando dovete passare dati da una
 DTO a un altro? Se no, come fate?

 ciao

 federico

>>>
>>>
> 
>



-- 
Response to : m.iv...@gmail.com

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

[bruno bossola bboss...@gmail.com [it-torino-java-jug]]

Mah, per esempio nei servizi REST raramente serializzo l'oggetto, ma una
"vista" di esso. Lo stesso in ingresso, ricevo una "vista" e da quella
ottengo il vero oggetto.
Questo per me e' l'esempio piu' comune, e faccio a mano, si, li testo di
solito perche' quando creo l'oggetto "vero" di solito passo parametri
(magari un repository) e c'e' della logica "vera" da disegnare.

Ciao,

Bruno.

2018-01-15 17:35 GMT+00:00 Tatiana Litvinova tatiana.litvin...@gmail.com
[it-torino-java-jug] :

>
>
> Ciao a tutti,
>
> Vorrei allargare la questione posta da Federico.
>
> 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)?
>
> Grazie,
> Tatiana
>
> вс, 14 янв. 2018 г. в 11:23, bruno bossola bboss...@gmail.com
> [it-torino-java-jug] :
>
>>
>>
>> Se il problema e' che da A devo costruire B, allora un metodo in A che si
>> chiama "buildB()": questo per "information expert" (GRASP)
>> ,
>>  e
>> se ci sono cose secondarie da usare nella conversione le passo come
>> parametro.
>>
>> In altri casi dipende... in genere cerco di assegnare la responsabilita'
>> a qualche oggetto che ha senso che ce l'abbia :)
>> Ciao,
>>
>> Bruno
>>
>>
>> 2018-01-12 17:35 GMT+00:00 Federico Fissore feder...@fsfe.org
>> [it-torino-java-jug] :
>>
>>>
>>>
>>> Ciao
>>>
>>> domandina del venerdì sera
>>>
>>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>>
>>> return ExpenseBuilder.anExpense()
>>> .withId(id)
>>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>>> .withDate(new Date())
>>> .withReason("Something pretty")
>>> .build();
>>>
>>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>>> presi da un altro bean via getter, oppure quest altro bean offre lui un
>>> metodo che restituisce un builder pre-popolato
>>>
>>> Anche voi siete abituati a fare così quando dovete passare dati da una
>>> DTO a un altro? Se no, come fate?
>>>
>>> ciao
>>>
>>> federico
>>>
>>
>> 
>

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

[Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug]]

Ciao a tutti,

Vorrei allargare la questione posta da Federico.

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)?

Grazie,
Tatiana

вс, 14 янв. 2018 г. в 11:23, bruno bossola bboss...@gmail.com
[it-torino-java-jug] :

>
>
> Se il problema e' che da A devo costruire B, allora un metodo in A che si
> chiama "buildB()": questo per "information expert" (GRASP)
> ,
>  e
> se ci sono cose secondarie da usare nella conversione le passo come
> parametro.
>
> In altri casi dipende... in genere cerco di assegnare la responsabilita' a
> qualche oggetto che ha senso che ce l'abbia :)
> Ciao,
>
> Bruno
>
>
> 2018-01-12 17:35 GMT+00:00 Federico Fissore feder...@fsfe.org
> [it-torino-java-jug] :
>
>>
>>
>> Ciao
>>
>> domandina del venerdì sera
>>
>> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>>
>> return ExpenseBuilder.anExpense()
>> .withId(id)
>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
>> .withDate(new Date())
>> .withReason("Something pretty")
>> .build();
>>
>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
>> presi da un altro bean via getter, oppure quest altro bean offre lui un
>> metodo che restituisce un builder pre-popolato
>>
>> Anche voi siete abituati a fare così quando dovete passare dati da una
>> DTO a un altro? Se no, come fate?
>>
>> ciao
>>
>> federico
>>
>
> 
>

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

[Federico Tolomei fede+ju...@s17t.net [it-torino-java-jug]]

In nessun ordine particolare:

- A mano:

 tBean.setFieldA(sBean.getFieldA());
 tBean.setFieldB(sBean.getFieldB());

- Builder

- BeanUtils / Dozer e compari

- Cose custom e truci con reflection

- il .convertValue dell'ObjectMapper di Jackson: hai tutte le feature di
Jackson (es i mixin) e probabilmente devi comunque esporre JSON.




Il giorno 12 gennaio 2018 18:35, Federico Fissore feder...@fsfe.org
[it-torino-java-jug]  ha scritto:

>
>
> Ciao
>
> domandina del venerdì sera
>
> Da qualche tempo vedo con crescente frequenza questo tipo di codice
>
> return ExpenseBuilder.anExpense()
> .withId(id)
> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING))
> .withDate(new Date())
> .withReason("Something pretty")
> .build();
>
> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono
> presi da un altro bean via getter, oppure quest altro bean offre lui un
> metodo che restituisce un builder pre-popolato
>
> Anche voi siete abituati a fare così quando dovete passare dati da una
> DTO a un altro? Se no, come fate?
>
> ciao
>
> federico
> 
>