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
