Всем привет,

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

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 где этот вопрос уже решен?

Спасибо

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

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

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

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

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

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

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

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

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

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

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

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

а использовать обертку при покладании в мапу?

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

C>а использовать обертку при покладании в мапу?

Спасибо, интересное предложение подумаю

Здравствуйте, 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 пункт тоже

trove? (hash strategy )
если ещё жив...

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

ЕНП>На каждом слое нужно своя имплементация hashCode и equals методов т.к. требуется работа с коллекциями но используется различная информация для сравнения и вычисления уникальности на каждом слое.
Не надо никаких переопределений! Не должны DTO логику сравнения сорержать, не должны. Я еще понимаю, если объект immutable или он будет пихаться в set для hibernate, но для целей бизнес логики это очень плохая практика.
А в твоем случае вижу следущее:
Объекты пихать не в set, а в map. В качастве ключа использовать immutable структуру, содержащую только требуемые поля ключа. В принципе эту структуру можно и и через рефлексию сгенерить. Можно без структуры, все нужные поля перед помещением в map сериализовать в строку, которую использовать в качестве ключа.
Но модифицировать equals для нужд бизнес логики — это очень и очень плохая идея.

On 27/07/10 15:44, ЕщеНеПридумал wrote:
> Изменить или написать свою имплементацию коллекций где для этих методов
> будет предусмотрен интерфейс стратегий как например для сортировки —
> Comparator.
> Я так и не пойму на хрена они не сделали тоже самое для hashCode и equals.
Потому что вряд ли есть такая ситуация, где hashCode и equals не может быть заменено Comparator-ом. Нет никаких проблем использовать TreeSet вместо HashSet.
Единственное, что приходит в голову — оптимизация. А её лучше делать по месту.
Вообще, имхо, hashCode и equals лучше рассматривать как конструкции языка, а не для реализации бизнес-логики.

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

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

ЕНП>>На каждом слое нужно своя имплементация hashCode и equals методов т.к. требуется работа с коллекциями но используется различная информация для сравнения и вычисления уникальности на каждом слое.
E>Не надо никаких переопределений! Не должны DTO логику сравнения сорержать, не должны. Я еще понимаю, если объект immutable или он будет пихаться в set для hibernate, но для целей бизнес логики это очень плохая практика.
E>А в твоем случае вижу следущее:
E>Объекты пихать не в set, а в map. В качастве ключа использовать immutable структуру, содержащую только требуемые поля ключа. В принципе эту структуру можно и и через рефлексию сгенерить. Можно без структуры, все нужные поля перед помещением в map сериализовать в строку, которую использовать в качестве ключа.
E>Но модифицировать equals для нужд бизнес логики — это очень и очень плохая идея.

На момент вычислений он уже immutable.
Потом мне по любому нужно реализовать алгоритм и я не вижу большого смысла в дублировании по вычленении ключа чтобы отдельно использовать его в map.
В GUI я тоже это учту если ключ в объекте будет меняться.
Т.к. большинство вычислений у меня предусмотрено в памяти а не в базе, я пока думаю распределить логику между объектами в зависимости от того какими данными они обладают.
Это как-бы не совсем TDO, извиняюсь что ввел в заблуждение.

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

.>On 27/07/10 15:44, ЕщеНеПридумал wrote:
>> Изменить или написать свою имплементацию коллекций где для этих методов
>> будет предусмотрен интерфейс стратегий как например для сортировки —
>> Comparator.

Чем было бы плохо иметь следующую конструкцию на ровне с Comparator:

SortedList sortedList = new SortedList( myComparator );

использовать также

Map sortedList = new HashMap( myHashingStrategy, myEqualizerStrategy ); // на оригинальность и правильность названия не претендую
Которые можно было бы например получить с помощью фактори метода из самого объекта

>> Я так и не пойму на хрена они не сделали тоже самое для hashCode и equals.
.>Потому что вряд ли есть такая ситуация, где hashCode и equals не может быть заменено Comparator-ом. Нет никаких проблем использовать TreeSet вместо HashSet.
.>Единственное, что приходит в голову — оптимизация. А её лучше делать по месту.
.>Вообще, имхо, hashCode и equals лучше рассматривать как конструкции языка, а не для реализации бизнес-логики.

Вы бы уже договаривали где ее родимую реализовавать?
В базе с помощью sql? В хранимых процедурах?

В моей задаче я считаю в памяти ей как раз самое место а уж грешно не использовать коллекции и т.д.

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

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

ЕНП>>>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. плохо вдвойне — сет может нарушать свои инварианты если на него посмотреть не из того потока. Бррр.

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

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

.>>On 27/07/10 15:44, ЕщеНеПридумал wrote:
>>> Изменить или написать свою имплементацию коллекций где для этих методов
>>> будет предусмотрен интерфейс стратегий как например для сортировки —
>>> Comparator.

ЕНП>Чем было бы плохо иметь следующую конструкцию на ровне с Comparator:

ЕНП>SortedList sortedList = new SortedList( myComparator );

ЕНП>использовать также

ЕНП>Map sortedList = new HashMap( myHashingStrategy, myEqualizerStrategy ); // на оригинальность и правильность названия не претендую

Тем что в java это запрещено см. доки к интерфейсам мапа\сета.

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

ЕНП>Map sortedList = new HashMap( myHashingStrategy, myEqualizerStrategy ); // на оригинальность и правильность названия не претендую
Есть еще TreeMap, можешь его использовать. Сдался тебе этот Hash

On 27/07/10 19:08, ЕщеНеПридумал wrote:

> SortedList sortedList = new SortedList( myComparator );
>
> использовать также
>
> Map sortedList = new HashMap( myHashingStrategy, myEqualizerStrategy );
> // на оригинальность и правильность названия не претендую
> Которые можно было бы например получить с помощью фактори метода из
> самого объекта
Так пиши "Map map = new TreeMap(myComparator);". Зачем тебе именно Hash?

> Вы бы уже договаривали где ее родимую реализовавать?
> В базе с помощью sql? В хранимых процедурах?
В смысле бизнес-логику? В особо сложных случаях я бы создавал DTO в слое DAO. Т.к. объекты уровня GUI могут довольно разительно отличаться от объектов уровня persistence.

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

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

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

.>>>On 27/07/10 15:44, ЕщеНеПридумал wrote:
>>>> Изменить или написать свою имплементацию коллекций где для этих методов
>>>> будет предусмотрен интерфейс стратегий как например для сортировки —
>>>> Comparator.

ЕНП>>Чем было бы плохо иметь следующую конструкцию на ровне с Comparator:

ЕНП>>SortedList sortedList = new SortedList( myComparator );

ЕНП>>использовать также

ЕНП>>Map sortedList = new HashMap( myHashingStrategy, myEqualizerStrategy ); // на оригинальность и правильность названия не претендую

GIV>Тем что в java это запрещено см. доки к интерфейсам мапа\сета.

Если ко всем правилам по реализации equals и hashCode добавить что должна использоваться одна и таже стратегия то проблем не вижу.
Причем стратегия задается на уровне коллекции а не объекта.
Ее можно разрешить задавать только при создании коллекции и не позволять менять у уже созданной.

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

ЕНП>На момент вычислений он уже immutable.
immutable не бывает на момент вычислений. Объект либо immutable, либо нет, и не зависит это от момента.

ЕНП>Потом мне по любому нужно реализовать алгоритм и я не вижу большого смысла в дублировании по вычленении ключа чтобы отдельно использовать его в map.
Тебе подсказали нормальное решение с использованием компараторов.

ЕНП>В GUI я тоже это учту если ключ в объекте будет меняться.
Не надо ничего учитывать. Чем меньше будет того, что требуется учитывать, тем меньше у тебя будет багов.

ЕНП>Т.к. большинство вычислений у меня предусмотрено в памяти а не в базе, я пока думаю распределить логику между объектами в зависимости от того какими данными они обладают.
ЕНП>Это как-бы не совсем TDO, извиняюсь что ввел в заблуждение.
Не надо запихивать логику в объекты, не надо. Простейшую можно (например если объект содержит список других объектов разных типов, то можно добавить несколько методов, чтоб возвращались определенные типы, или допустим какой нибудь главный объект из этого списка — все, остальное не надо!), более сложную — не надо! Сам черт потом в этом коде ногу сломит, классы будут километровой длины. Решение у тебя типовое, не надо городить черти что — используй Entity объекты для хранения данных и всякие менеджеры и сервисы для реализации бизнес логики, в объекты ничего не надо помещать!
Не будешь следовать нормальным принципам разработки ПО — работать то все будет. Вот только багов будет немеряно, при малейшем изменении все придется переписывать, и костыли будут такие, что кроме тебя никто не разберется. А через несколько лет ты сам будешь не способен разобраться в том, что написал. А тот, кто будет после тебя с этим разбираться — тот автора потом проклянет.

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

ЕНП>>>Map sortedList = new HashMap( myHashingStrategy, myEqualizerStrategy ); // на оригинальность и правильность названия не претендую

GIV>>Тем что в java это запрещено см. доки к интерфейсам мапа\сета.

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

http://java.sun.com/javase/6/docs/api/java/util/Map.html

Там же английским по белому написано

Many methods in Collections Framework interfaces are defined in terms of the equals method.

Ты можешь делать любые (в том числе и с myEqualizerStrategy) коллекции, но если реализуешь Map или Set ты должен следовать этим правилам — equals, equals и только equals и никаких стратегий. LSP ведь никто не отменял.

ЕНП>>Т.к. большинство вычислений у меня предусмотрено в памяти а не в базе, я пока думаю распределить логику между объектами в зависимости от того какими данными они обладают.
ЕНП>>Это как-бы не совсем TDO, извиняюсь что ввел в заблуждение.

E>Не надо запихивать логику в объекты, не надо. Простейшую можно (например если объект содержит список других объектов разных типов, то можно добавить несколько методов, чтоб возвращались определенные типы, или допустим какой нибудь главный объект из этого списка — все, остальное не надо!), более сложную — не надо! Сам черт потом в этом коде ногу сломит, классы будут километровой длины.

Вообще-то как раз чтобы не было ситуации "классы будут километровой длины" и нужно распределять логику по объектам предметной области. Всё ООП на этом принципе построено. А ситуацию, когда в объектах предметной области нет логики, ещё сам Фаулер отнёс к антипаттернам.
Основные проблемы начинаются, когда одни и те же объекты начинают таскать по разным уровням приложения тогда как логика в этих уровнях совсем отличная. Универсального решения тут нет — где-то хорош один подход, где-то другой... И anemic domain model, которую вы пропагандируете далеко не всегда есть лучшее решение...

E> Решение у тебя типовое, не надо городить черти что — используй Entity объекты для хранения данных и всякие менеджеры и сервисы для реализации бизнес логики, в объекты ничего не надо помещать!
E>Не будешь следовать нормальным принципам разработки ПО — работать то все будет. Вот только багов будет немеряно, при малейшем изменении все придется переписывать, и костыли будут такие, что кроме тебя никто не разберется. А через несколько лет ты сам будешь не способен разобраться в том, что написал. А тот, кто будет после тебя с этим разбираться — тот автора потом проклянет.

Если писать криво — то конечно проклянёт. Но чтобы писать "некриво" мало следовать каким-то универсальным простым рецептам. "Серебряной пули нет".

SA>Основные проблемы начинаются, когда одни и те же объекты начинают таскать по разным уровням приложения тогда как логика в этих уровнях совсем отличная. Универсального решения тут нет — где-то хорош один подход, где-то другой... И anemic domain model, которую вы пропагандируете далеко не всегда есть лучшее решение...

дополните, пожалуйста, тезис:
"anemic domain model, не всегда есть лучшее решение в контексте "когда одни и те же объекты начинают таскать по разным уровням приложения"."
примерами частных решений на reach(или ... ?) модели, областью применения(критериями применимости)... и это не срочно.
контекст — "одни и те же объекты начинают таскать по разным уровням приложения"
если это вас не затруднит.
спасибо.

Здравствуйте, Аноним, Вы писали:

SA>>Основные проблемы начинаются, когда одни и те же объекты начинают таскать по разным уровням приложения тогда как логика в этих уровнях совсем отличная. Универсального решения тут нет — где-то хорош один подход, где-то другой... И anemic domain model, которую вы пропагандируете далеко не всегда есть лучшее решение...

А>дополните, пожалуйста, тезис:
А>"anemic domain model, не всегда есть лучшее решение в контексте "когда одни и те же объекты начинают таскать по разным уровням приложения"."
А>примерами частных решений на reach(или ... ?) модели, областью применения(критериями применимости)... и это не срочно.
А>контекст — "одни и те же объекты начинают таскать по разным уровням приложения"
А>если это вас не затруднит.

Всё зависит от конкретной ситуации и способа разделения уровней. Пара примеров:

1) Обычное Web-приложение. Наличие бизнес-логики в этом случае, как правило не мешает работе визуальной. Визуальный уровень разбивается на две части — броузерная (у которой своя реализация объектов) и web-серверная, которая просто отвечает за взаимодействие с бизнес-уровнем. Преимуществ у голых объектов тут нет никаких.
2) Приложение на GWT. Напрямую в визуальном слое использовать объекты с логикой нельзя — у GWT урезаная Java. Однако, применив автоматическую генерацию и штатную возможность подмену реализации вполне можно подсунуть GWT объекты с отрезаной логикой. Поднять такую систему, конечно, сложнее на начальном этапе (надо написать генератор), зато потом сплошные плюсы: объект присутствует в одном экзепляре (нет необходимости создавать и поддерживать DTO), можно использовать нормальную rich domain model и т.д. и т.п.