Re[3]: Изменение hashCode и equals методов в runtime-ме
От: GarryIV  
Дата: 27.07.10 16:31
Оценка:
Здравствуйте, ЕщеНеПридумал, Вы писали:

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


ЕНП>>>1. Создать свой класс для каждого слоя с нужными hashCode и equals и конвертировать мапперами DTO to DTO при переходе данных между слоями.

ЕНП>>>Этот подход мне не нравится т.к. если информации будет много (правда в этом я еще не уверен) то конвертация может занимать время и если данных будет действительно много то я скорее всего буду вносить изменения в базу сразу после изменения данных чтобы по прошествии работы юзер не ждал пока все сохранится.
ЕНП>>>Да и информация об объекте одинаковая, просто на GUI она только информативная.
GIV>>+1. Можно оставить в DTO _только функции хранения данных_. Логику специфичную для слоя писать в отдельных классах, которые только используют (агрегируют) те DTO.

ЕНП>да там и так только данные, но они все нужны на всех слоях

ЕНП>на базе все данные сохраняются и с GUI и с вычеслений
ЕНП>на GUI данные с вычислений только отображаются
ЕНП>не охота заниматься дублированием кода

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

ЕНП>>>3. Изменить или написать свою имплементацию коллекций где для этих методов будет предусмотрен интерфейс стратегий как например для сортировки — Comparator.

ЕНП>>>Я так и не пойму на хрена они не сделали тоже самое для hashCode и equals.
ЕНП>>>Довольно трудозатратно по моему мнению, еще нужно убедится что все работает и написать кучу unit test-тов.
GIV>>-1000

ЕНП>>>Кстати нет ли случайно готовых unit test-тов для стандартной java collection?

GIV>>ХЗ. Должны быть

ЕНП>>>4. Можно использовать паттерн ThreadLocal. Т.е. создать пул по потокам и там устанавливать текущую коллекцию к потоку.

ЕНП>>>А уже в объекте в метода hashCode и equals брать установленную на текущий момент стратегию.
ЕНП>>>Плюс с переходом на Scala можно будет оформить это в виде scope-пов.
GIV>>-1000

ЕНП>интересны аргументы почему 4 пункт удостоен -1000? да и 3 пункт тоже


3. плохо потому что открываем javadoc к java.util.Set и читаем

A collection that contains no duplicate elements. More formally, sets contain no pair of elements e1 and e2 such that *e1.equals(e2)*

ты хочешь это нарушить я так понял.

4. плохо вдвойне — сет может нарушать свои инварианты если на него посмотреть не из того потока. Бррр.
WBR, Igor Evgrafov
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.