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 [email protected]
[it-torino-java-jug] <[email protected]> ha scritto:
>
>
> Ciao,
>
> 2018-01-22 9:29 GMT+11:00 Ramon Flamia [email protected]
> [it-torino-java-jug] <[email protected]>:
>
>>
>>
>> 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 : [email protected]
