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. Per risolverlo vogliamo usare uno schema implicito al posto di quello esplicito, perdendo tutti i vantaggi di quest'ultimo, per ritrovarci comunque un mucchio di trasformazioni inutili, ma fatte più facilmente.. Mi convince di più l'approcio di Bruno: faccio la trasformazione soltanto laddove mi serve (la perdita di uniformità è probabilmente il male minore). E se usassimo un linguaggio diverso da java forse in alcuni casi potremmo evitare anche quella: mi viene da pensare alla manipolazione dell'interfaccia degli oggetti a runtime di groovy, ma ci devo riflettere per capire se è una porcata o può essere realmente utile in questo caso. Rimarrebbero soltanto le trasformazioni che in effetti hanno senso come tali: cioè quando ai confini del sistema lo schema cambia, i dati sono rappresentati in maniera differente. > Se fossi confinato a Java userei l'approccio a mappa ma se potessi > passerei a Kotlin. > 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? 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. > A volte l'azienda non può pensare, si limita ad adeguarsi agli standard del cliente... Ciao, Tatiana >
