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

2018-01-16 Thread bruno bossola bboss...@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é.
>
Facendo retrospettiva, per me devono verificarsi queste due condizioni (
*entrambe*):

   - c'e' un paradigm shift (esco dal mondo OO per entrare nel relazionale,
   request/response, publish/subscribe, ecc.ecc.)
   - ho bisogno di una rappresentazione diversa (devo inserire una
   serializzazione che non riesco a rappresentare, mi esporrei a un problema
   di sicurezza, etc.etc)

E poi YAGNI, se posso lo evito. Ho sempre tempo a rifattorizzare dopo.
Prendi le mie considerazioni con le molle pero' perche':

   - sono un agilista convito, affanculo BDUF, l'architettura evolvera' ed
   emergera' ad ogni iterazione
   - 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


*>> L'uso dei builder per costruire oggetti nei test è stato reso popolare
dal GOOS*
>>
>Il fatto che tu sostenga che i builder siano stati resi popolari dal TDD
mi sembra a dir poco opinabile [...]
>
A riguardo di quello che dice Matteo, penso che tu l'abia intepretato male.
Quando dice "*...**l'uso dei builder per costruire oggetti nei
test..**" *intende
esattamente questo, e' una frase da leggere tutta di un fiato: non e'
un'affermazione generale su come i Builder possano essere stati resi
popolari.

Se vogliamo parlare in generale di popolarita', pero', date un'occhiata ad
apache-http:

   - 3,x: Apache scopre il factory pattern, tutto e' una factory
   - 4.x: Apache scopre il builder pattern: tutto e' un builder

Raga, se scoprono il Visitor siamo fottuti :)

Ciao,

Bruno


2018-01-15 21:47 GMT+00:00 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

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

2018-01-16 Thread 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?

2018-01-16 Thread Andrea Cerisara andreaceris...@gmail.com [it-torino-java-jug] 
Secondo me il problema è dettato principalmente dalla verbosità di Java
(anche noi abbiamo spesso discussioni sul quando/come/se creare bean
appositi).

A lavoro stiamo sperimentando parti di backend con Kotlin e devo dire che
il problema è molto meno evidente.

Abbiamo una BFF scritta in Kotlin che:
 1. prende json e lo deserializza in un bean
 2. converte il bean in un altro, facendo qualche semplice conversione /
arricchendo il bean
 3. chiama il servizio

Duplichiamo tutto, sia lato REST che lato servizi (nel senso che il vero e
proprio oggetto di dominio, o aggregate nel nostro caso, è un altro
ancora), ma con le data classes di Kotlin ed i named arguments il codice
rimane pochissimo e molto leggibile (così a naso, nel nostro prototipo,
direi almeno 50% meno).

2018-01-16 11:51 GMT+01:00 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
> 
>



-- 
** Think about the environment before printing

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

2018-01-16 Thread 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?

2018-01-16 Thread 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?

2018-01-16 Thread 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?

2018-01-16 Thread 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?

2018-01-16 Thread Roberto Franchini ro.franch...@gmail.com [it-torino-java-jug] 
2018-01-17 8:08 GMT+01:00 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.
>
> It's my time.
Quando Fede ebbe la prima visione, io c'ero.
E la seguii.
Cosi' tanto che ancora oggi esiste un sistema, che gestisce qualcosa come
10 milioni di messaggi al giorno, che usa quel modo di sviluppare.
Ne ho riscritta una incarnazione, da zero , in Kotlin (spero di metterla OS
presto).
Perche' e' flessibile, testabile, facile fare ingestione dei dati da fonti
diverse e normalizzarli.
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

FRANK



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