Ciao a tutti, ho trovato molto interessante questa discussione. I due approcci che preferirei sono quello della mappa e l'uso di Kotlin.
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. Se fossi confinato a Java userei l'approccio a mappa ma se potessi passerei a Kotlin. Hanno gia' fatto vedere esempi di data classes. Io avrei probabilmente un file con le data classes del Layer 1: data class MyClassLayer1(val name: String, val age: Int, val address: Address) // seguono le altre data classes del layer 1 e un file con le data classes del Layer 2: data class MyClassLayer2(val name: String, val age: Int) // seguono le altre data classes del layer 2 qui potrei anche metterci i metodi di conversione. Ad esempio aggiungengo un metodo agli oggetti del layer 1 per convertirli nell'equivalente di Layer2: fun MyClassLayer1.toLayer2() = MyCLassLayer2(name, age) // questo e' un metodo con un solo statement volendo posso anche esplicitare i nomi delle proprieta': fun MyClassLayer1.toLayer2() = MyCLassLayer2(name=name, age=age) Per cui lo uso cosi' oggettoLayer2 = oggettoLayer1.toLayer2() Poi magari se le classi iniziassero ad avere 4-5 proprieta' o avessi diversi casi in cui in pratica mi devo trasferire tutte le proprieta' andrei giu' di reflection, anche qui decisamente semplice da fare in Kotlin.. Ecco, onestamente se penso ad esempi come questo mi viene difficile giustificare l'uso di Java rispetto a Kotlin. In alcuni progetti open-source magari si decide di usare Java perche' lo conoscono in di piu' e quindi ci sono piu' contributor. In un'azienda pero' investirei 2-3 giorni in formazione su Kotlin. Se poi la tua azienda sta pensando "eh ma non e' ancora maturo" o "e' troppo nuovo" considera che Kotlin e' stato approvato da Google come linguaggio ufficiale per lo sviluppo di applicazioni Android. Se la tua azienda non riesce a reggere il passo di un colosso e deve avere molta piu' cautela, be', penso che tu abbia un problema. Federico T. 2018-01-17 22:57 GMT+01:00 bruno bossola [email protected] [it-torino-java-jug] <[email protected]>: > > > 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 [email protected] > [it-torino-java-jug] <[email protected]>: > >> >> >> ср, 17 янв. 2018 г. в 14:29, bruno bossola [email protected] >> [it-torino-java-jug] <[email protected]>: >> >>> 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 >> >>> > > -- Website at https://tomassetti.me GitHub https://github.com/ftomassetti
