avoir deux classes différentes: A et B. Ils ont exactement les mêmes noms de champs. Supposons que leur définition soit ci-dessous:
B objectB = B.builder() .attriA(objectA.getAttriA()) .attriB(objectA.getAttriB()) .attriC(objectA.getAttriC()) .build();
3 Réponses :
En général, Java adhère à la notion de typage nominal et non de dactylographie structurelle. Pour amener cet argument à la maison, imaginez ces deux interfaces: dans une langue structurelle, quelqu'un va avoir un vraiment, vraiment em> mauvaise surprise. Dans une langue nominale, ce n'est pas un problème (et note que les types sont Un principe similaire s'applique ici: un A peut ressembler beaucoup à un Beaucoup comme un B, mais à Java, un A n'est pas un B. En fait, le champ «attria» n'a absolument aucune relation dans le domaine «attria» de B. Le fait qu'ils aient ainsi avoir le même nom et le même type est une coïncidence pure. En fait, c'est un détail de mise en œuvre (API privé); Vous devriez être capable de renommer le champ et aucun code existant ne devrait se soucier de cela ou de casser. P> Par conséquent, vous ne devriez pas le vouloir; ce n'est pas Java-Esque. P> Mais si vous insistez, éventuellement Mapstruct peut faire quelque chose pour vous ici (Je ne le recommanderais pas, cependant!). P> P> java.util.list code> et
java.awt.list code> ne sont en aucun cas ni de forme interchangeable, n'importe où, dans l'écosystème Java. Guns and Greatmas). P>
Etant donné que A code> et
B code> ne semble pas avoir rien de commun à l'exception des mêmes attributs de sondage coïncidents, au moins vous n'avez pas dit qu'ils hériter de chaque Autre, vous pouvez écrire votre propre méthode ou fonction de mapper. Vous pouvez ensuite appeler cette fonction chaque fois que vous souhaitez créer un
B code> à partir d'un
A code> et épargnez-vous de taper:
Il y a une chose que vous attendez dans les beansutils d'Apache. https://mvnrepository.com/artifact/commons-beanutils/commons- Beansutils / 1.9.2
BeanUtils.copyProperties(objectB, objectA);