Шаблон преобразования объектов

Question

У меня есть несколько разных классов, поступающих из внешних источников (неизменяемых), которые представляют одну и ту же концепцию. Например Address. У меня есть com.namespace1.Address (с полями houseNum, street, city), com.namespace2.Address (с полями h, s, c), namespace3.com.CoolAddress (с полями house_num, street, city).

Проблема в том, что некоторым веб-службам, которые я использую, требуются определенные типы объектов Address, поэтому мне необходимо создать com.namespace1.Address с учетом namespace3.com.CoolAddress. Поля достаточно легко сопоставить, но я ищу образец того, как это сделать.

С моей точки зрения, экземпляр объекта AddressConverter не имеет смысла, так как нет состояния (только поведение) и когда классы имеют только поведение, он сводится к статическим методам в служебном классе. В долгосрочной перспективе, когда мне нужно отобразить новые объекты друг на друга, у меня есть одно место для добавления / изменения / удаления методов. То, как это сделано, может измениться, но я знаю, где находится код (в одном месте), и могу изменить отображение, когда мне нужно.

Мысли

Answer 1

Я думаю, что вы ищете фабричный класс . Фабричный шаблон используется, когда вам нужно создать экземпляр одного из нескольких связанных классов, который должен определять фабрика, а не разработчик.

См. http://en.wikipedia.org/wiki/Factory_method_pattern

Вы правы, пытаясь хранить всю эту бизнес-логику в одном месте вместо того, чтобы выполнять ClassOne.toClassTwo (), ClassOne.toClassThree (), ...

Самым гибким способом реализации этого (но не самым простым), который я могу придумать, было бы начало фабрики с простого класса, содержащего только основные общие методы, и добавление обработчиков в Hashtable или другой контейнер. Таким образом, вам не нужны конкретные реализации всех возможных комбинаций функций.

Конечно, было бы быстрее иметь конкретную реализацию для каждого возможного варианта адреса, но было бы значительное количество дублированного кода, и было бы немного сложнее добавить новые типы классов адресов.

Answer 2

Поскольку вы не можете изменять сами классы, я бы предложил реализацию шаблона Adapter для каждого направления. Как вы сказали, сами методы адаптера могут быть статическими, но вы можете сгруппировать оба направления внутри одного класса, чтобы логика находилась в одном месте.

В конце дня вы будете выполнять одну и ту же задачу, независимо от того, как вы ее называете, или где вы положили код. Я бы посоветовал, чтобы оба направления находились в одном и том же файле, так как они часто требуют обновления при изменении любого из направлений.

Answer 3

Нужны ли классы для вывода final? Если нет, вы можете создать их подклассы для создания правильных адаптеров . В противном случае я бы пошел с предложением dj_segfault о фабрике с таблицей обработчиков.

Или, подождите, вам нужен только веб-сервис? Если это так, то не должно быть никаких причин, по которым ваши реализации типов данных не могут быть адаптерами, обертывающими входные типы данных, или каким-либо вашим промежуточным объектом.

Answer 4

Если вы всегда конвертируете в один и тот же класс, я бы оставил его простым и поместил весь код конвертации в этот класс, не заботясь о фабриках и тому подобном, особенно если вы имеете дело только с парой разных классов. Почему всегда должен быть сложный шаблон для этих вещей?!

public class A {

    ...

    public static A convertB(B b) {

    ...

    }
}