Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, ЕщеНеПридумал, Вы писали:

ЕНП>>Всем привет,

ЕНП>>Есть три слоя:

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

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

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

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

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

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

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

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

ЕНП>>Кстати нет ли случайно готовых unit test-тов для стандартной java collection?
GIV>ХЗ. Должны быть

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

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