2013-06-14 3 views
0

Я пытаюсь реализовать конвертер между различными типами в java: У меня есть суперкласс foo, который имеет 2 подкласса: foo1 и foo2, у меня также есть 2 несвязанных других класса bar1 и bar2 и Я пытаюсь реализовать конвертер от bar1 до foo1 и от bar2 до foo2 (и наоборот).конвертер между различными типами Java

Поскольку у меня есть наследование здесь, я думал, что должен быть создан интерфейс с общим типом (который будет bar1 или bar2), и он определит функции, необходимые для преобразования, я также хочу, чтобы конвертер был одним общий конвертер для bar1 и bar2, и я думал, что он должен каким-то образом использовать реализации интерфейса. Лучшая идея или ссылка на такой пример реализации будут высоко оценены. Я также искал шаблон дизайна, который описывает такую ​​схему, но может найти подходящий ... Любые идеи?

ответ

1

Я бы выбрал общий интерфейс и общий родительский класс и, возможно, также использовал шаблон построения.

a common partialFooBar interface 
a common fooBarChimera parent class 

Вы могли бы потенциально поставить конвертер в родителю fooBarChimera (и обеспечить необходимые дополнительные детали для завершения из какой вы хотите.

Вы также можете использовать шаблон строитель.

в плоть его немного ...

т.е. первый класс

partialFooBarBuilder 

имеет простые стандартные конструкторы и методы настройки.

Окончательный метод затем «преобразует» этот класс в «полномасштабную» версию или fooBarChimera, которая тогда должна иметь только методы «getter».

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

так что вы в конечном итоге с Somthing как ...

public class buildpartFooBar implement fooBarCommon{ 
//fooBarCommon is the interface the enforces the commonality of between the 2 objects.  

public buildPartFooBar(){...} 

...[various setter methods here ....] 

//make the different types of object we may become 
private foo1 makeFoo1(iNeedThisToBeAFoo1 object){...} 
private foo2 makeFoo2(iNeedThisToBeAFoo2 object){...} 
private bar1 makeBar1(iNeedThisToBeABar1 object){...} 
private bar2 makeBar2 (iNeedThisToBeABar2 object){...} 
private fooBarChimera makeChimera(){...} 

} // конец класса buildPartFooBar

Тогда просто включить метод makeFooFromBar, где вы возвращаете foo1 или Foo2 или независимо от того, что вам нравится, вы, скорее всего, сделаете это с помощью статического метода в вашем классе fooBarChimera

Помните, что вам нужно будет разобраться с ситуацией, в которой ваши преобразованные строки и фью связаны друг с другом (возможно, вам потребуется реализовать некоторые форма сбора t hat имеет барный ключ и объект foo, или, возможно, это должно быть реализовано в вашем fooBarChimera где-то).

Вы можете решить, что foo и bar также нуждаются в сопоставимых методах, например, снова может быть разумным включить их в fooBarChimera в качестве статического сравнения. Таким образом вам нужно только написать его один раз в родительском.

couldThisFooBeBar

и

couldThisBarBeFoo

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

Вам также нужно будет решить, является ли преобразование 2-м способом, foo может быть баром, но панель может быть совместима с 2 foos.

В этом случае вы можете перейти к базе данных, которая может обрабатывать подобные вещи и хранить в ней объекты foo и bar, это может быть проще, чем настраиваемый класс colection, особенно если вы даете каждому foo и запретить uniquie objectID (guid).

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

что-то, что я мог бы сделать для удовольствия .... как, когда я смоделировал устаревшую БД с точки зрения коллекций java, только для того, чтобы понять, насколько я был глупым, и просто преобразовал его в более разумную БД.

Дэвид

+1

Кажется, очень хорошая идея и начальная точка, и я постараюсь реализовать ее таким образом. Большое спасибо! Причина, в которой я нуждаюсь, состоит в том, чтобы преобразовать несколько записей таблиц DB в один объект типа, потому что позже мне нужно сделать много вычислений в коллекции этого объекта. – DiSol

+0

Еще лучше/проще, вы можете получить скрипт выбора sql для объединения необходимых таблиц, а затем моделировать класс java для этой информации. Класс java может даже иметь ссылку на публичный статический (то есть не изменяемый) оператор SQL select (вероятно, это должна быть хранимая процедура), которая может повторно запускать ваш запрос через определенные промежутки времени (или вы можете заставить свою СУБД сделать это за вас, и поддержите его через ваш класс java. Спасибо, что приняли ответ. – DaveM

1

Адаптер - это шаблон desgin http://en.wikipedia.org/wiki/Adapter_design_pattern для преобразования одного типа в другой.

Создание новых объектов из других объектов будет «прототипом».

Или просто создание новых экземпляров использует «фабрику» или «строитель».

+0

адаптер не подходит здесь, потому что, как я понял adapteenig между различными интерфейсами во время выполнения при вызове для функции, которую он называет нужную функцию другого интерфейса, но то, что я пытаюсь сделать, это создать новые объекты из других – DiSol

+0

@DimaSolomonov обновлен – NimChimpsky

+0

Шаблон прототипа, когда у меня есть те же объекты, но в моем случае нет прототипа, но шаблон создателя кажется интересной идеей, я проверю его, спасибо! – DiSol

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