Зеркальное отражение объекта в другом в java - PullRequest
Новая
       55

Зеркальное отражение объекта в другом в java

0 голосов
/ 09 июля 2020

Имеют два разных класса: A и B. У них точно такие же имена полей. Предположим, их определение приведено ниже: 

import lombok.Builder;
import lombok.Data;

@Data
@Builder
public class A {
  private String attriA;
  private String attriB;
  private String attriC;
}


import lombok.Builder;
import lombok.Data;

@Data
@Builder
public class B {
  private String attriA;
  private String attriB;
  private String attriC;
}

Предположим, у меня есть экземпляр A, objectA, и я хочу перевести его в B. При ручной работе это будет выглядеть так: 

B objectB = B.builder()
        .attriA(objectA.getAttriA())
        .attriB(objectA.getAttriB())
        .attriC(objectA.getAttriC())
        .build();

Вопрос:

Кажется, я повторяю те сеттеры. Любая библиотека или подходы, с помощью которых мне не нужно писать эти повторяющиеся сеттеры? Чувствуя, мы можем использовать рефлексию, но не знаем точно, как это сделать.

Ответы [ 3 ]

2 голосов
/ 09 июля 2020

В целом, java придерживается понятия номинальной типизации, а не структурной типизации. Чтобы понять этот аргумент, представьте себе эти два интерфейса: 

public interface Camera {
    public void shoot(Person target);
}

public interface Gun {
    public void shoot(Person target);
}

На структурном языке кого-то ждет действительно, действительно неприятный сюрприз. На номинальном языке это не проблема (обратите внимание, что типы полностью распределены по именам - у них есть имя пакета, то есть даже с омонимами вы не столкнетесь с какими-либо проблемами. java.util.List и java.awt.List никоим образом и не взаимозаменяемы, нигде в экосистеме java. Guns and Grandmas).

Здесь применяется аналогичный принцип: A может выглядеть чертовски похоже на B, но в java A не является B. На самом деле, поле 'attriA' не имеет абсолютно никакого отношения к полю 'attriA' B. Тот факт, что у них так случилось, что у них одно и то же имя и один и тот же тип, - чистое совпадение. Фактически, это деталь реализации (частный API); у вас должна быть возможность переименовать поле, и никакой существующий код не должен заботиться об этом или сломаться.

Следовательно, вам это не нужно; это не java -esque.

Но если вы настаиваете, возможно, MapStruct может что-то для вас сделать (хотя я бы не рекомендовал это!).

0 голосов
/ 10 июля 2020

От Apache в BeanUtils вы точно ожидаете одного. https://mvnrepository.com/artifact/commons-beanutils/commons-beanutils/1.9.2

BeanUtils.copyProperties(objectB, objectA);
0 голосов
/ 10 июля 2020

Поскольку A и B, похоже, не имеют ничего общего, кроме совпадающих по совпадению звуковых атрибутов, по крайней мере вы не сказали, что они наследуются друг от друга, вы можете написать свой собственный метод сопоставления или функция. Затем вы можете вызывать эту функцию всякий раз, когда хотите создать B из A и сэкономить время, набрав: 

Function<A,B> mirrorToB = a ->  B.builder()
                                 .attriA(objectA.getAttriA())
                                 .attriB(objectA.getAttriB())
                                 .attriC(objectA.getAttriC())
                                 .build();

B objectB = mirrorToB.apply(objectA);
...