Изменение hashCode и equals методов в runtime-ме
От: ЕщеНеПридумал  
Дата: 27.07.10 12:44
Оценка:
Всем привет,

Есть три слоя:

GUI (Web и возможно Java Web Start)
Server Side по вычислениям заданных данных
База данных — hibernate (или Active record)

Есть например объект Point, который участвует во всех трех слоях.
Но пока написан только слой "Вычислений SS" в виде standalone чтобы легче тестировать.

На каждом слое нужно своя имплементация hashCode и equals методов т.к. требуется работа с коллекциями но используется различная информация для сравнения и вычисления уникальности на каждом слое.

Я вижу следующие способы решения этой проблемы:

1. Создать свой класс для каждого слоя с нужными hashCode и equals и конвертировать мапперами DTO to DTO при переходе данных между слоями.
Этот подход мне не нравится т.к. если информации будет много (правда в этом я еще не уверен) то конвертация может занимать время и если данных будет действительно много то я скорее всего буду вносить изменения в базу сразу после изменения данных чтобы по прошествии работы юзер не ждал пока все сохранится.
Да и информация об объекте одинаковая, просто на GUI она только информативная.

2. Модифицировать сам объект. Т.е. сделать там несколько реализаций и предварительно устанавливать у объекта какую стратегию.
Тоже по моему хреново. Все равно нужно не забывать оббегать или устанавливать нужную стратегию до помещения объекта в коллекцию.
Короче геморройно и можно наплодить кучу багов.

3. Изменить или написать свою имплементацию коллекций где для этих методов будет предусмотрен интерфейс стратегий как например для сортировки — Comparator.
Я так и не пойму на хрена они не сделали тоже самое для hashCode и equals.
Довольно трудозатратно по моему мнению, еще нужно убедится что все работает и написать кучу unit test-тов.
Кстати нет ли случайно готовых unit test-тов для стандартной java collection?

4. Можно использовать паттерн ThreadLocal. Т.е. создать пул по потокам и там устанавливать текущую коллекцию к потоку.
А уже в объекте в метода hashCode и equals брать установленную на текущий момент стратегию.
Плюс с переходом на Scala можно будет оформить это в виде scope-пов.

Пока думаю остановится на 4 пункте. Если есть какие минусы то буду благодарен их услышать.
Возможно уже есть какие-нибудь opensource где этот вопрос уже решен?

Спасибо
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.