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

.>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? В хранимых процедурах?

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