Преобразование объектов данных - метод экземпляра против статического метода

Предположим, что существует два объекта, например. один представляет собой открытый API (JSON) и другой, который представляет модель (объект JPA). У них есть некоторые различия, но большинство временных полей являются общими.Преобразование объектов данных - метод экземпляра против статического метода

class A { 
    String name; 
} 

class B { 
    String name; 
}

Заметим, что для упрощения этих классов я просто упрощаю эти классы.

Мы должны преобразовать один в другой, чтобы этот дизайн работал правильно.

С одной стороны у нас есть методы экземпляра. Это кажется интуитивным подходом. У нас уже есть объект, поэтому метод экземпляра кажется логичным решением. Доступ к полям прост. Он также легко читается и понимает код. Он связывает один объект с другим, но они все равно должны быть парой.

static class A { 
    String name; 

    B toB() { 
     B b = new B(); 
     b.setName(name); 
     return b; 
    } 
}

Другой подход использует статический метод. Кажется, это больше похоже на шаблон строителя. Объект построен на основе зависимостей. Метод преобразования может быть перегружен и при необходимости использовать разные входные данные, что добавляет гибкости. Тем не менее, статический метод не очень хорошо работает с парадигмой ООП в целом.

static class A { 
    String name; 

    static A from(B b) { 
     A a = new A(); 
     a.setName(b.getName()); 
     return a; 
    } 
}

В настоящее время обсуждается команда, подход которой лучше с точки зрения ООП? Может ли кто-нибудь из них считаться лучшей практикой? Или, может быть, есть другое решение, которое мы должны применить?

Проще говоря - какой лучший подход в этом случае?

источник

2016-10-24 waste

Вы рассматриваете ситуацию, когда у вас есть 2 классов, которые подобны (и частично взаимозаменяемыми), но каждый из них подходит для нужд конкретный прецедент лучше. Это в значительной степени относится к теме «Array vs. Collection». В JDK вы получаете вспомогательные классы (utils), которые облегчают преобразование: см. java.util.Arrays.asList().

Вот как я поступил - создайте отдельный класс для преобразования. Таким образом, вы не связываете классы, и вы можете расширить возможности преобразования (например, в класс C), создать «подключаемые» делегаты преобразования и т. Д. Звучит как гораздо более гибкий вариант для меня.

источник

2016-10-24 06:41:42

Это кажется хорошей идеей, и я уже рассмотрел ее, но если мы будем следовать примерам JDK, существует также метод 'java.time.LocalDateTime # toLocalDate' или' java.util.stream. поток # toArray'. JDK, похоже, не согласуется с дизайном. – waste

Я не думаю, что это так. В частности, 'java.util.stream.Stream # toArray' - это способ обработки результата, а не самого потока. 'Arrays # asList', с другой стороны, преобразует два семантически похожих класса. С некоторой абстракцией вы можете сказать, что 'Stream' больше, чем' Array', но 'List' - это просто другая реализация' Array'. Вот почему последнее преобразование выполняется методом использования, в то время как первый явно является методом «Потока». –

Второй будет хороший подход, так как он следует шаблон проектирования и обеспечивает гибкость

источник

2016-10-24 06:36:10

Преобразование объектов данных - метод экземпляра против статического метода

ответ

Смежные вопросы