Xpoint
   [напомнить пароль]

Какие же замечательные коллекции есть в Java!

Метки: [без меток]
[арх]
2006-06-17 12:59:40 [обр] 30-ый(59/584)[досье]

Тема создана по мотимам темы Почему в Java нет полей типа "property" из Delphi как ответ на вопрос:

А вот это очень интересно. Расскажите, пожалуйста! Где вы применяли LinkedList, TreeMap, TreeSet?

TreeSet мой любымый тип. Когда я от EJB получаю набор подчиненных объектов (вагоны у поезда) их часто надо сортировать. Причем сортировать по-разному - по типу, владельцу, номеру и т.д. Так вот компаратор выглядит значительно элегантнее и быстрее, чем перезапрос сервера с соответсвующим EJB-QL запросом. Про элементарную алфавитную сортировку какого-нибудь комбобокса я уж и не говорю.

При этом сортировка занимает 2 строки.

sorted = new TreeSet(comparetor);
sorded.addAll(unsorted);

TreeMap используется с аналогичной целью. Тут для сортировки объектов по одному из полей вместо компаратора это поле выносится в ключ таблицы.

Как использовать LinkedList достаточно внятно сказано в документации:

In addition to implementing the List interface, the LinkedList class provides uniformly named methods to get, remove and insert an element at the beginning and end of the list. These operations allow linked lists to be used as a stack, queue, or double-ended queue (deque).

Что же касается альтернативных объектов из 1.1, так Sun вроде недвусмысленно намекает, что новые объекты по причине отказа от потоко-безопасности работают быстрее. Т.к. программы на Java часто на половину состоят из работы с коллекциями, я не вижу причин терять дополнительную производительность на обеспечении излишней потокобезопасности.

спустя 6 минут [обр] 30-ый(59/584)[досье]

Позволю себе еще прокоментировать фразу Даниэль Алиевский[досье]:

Поэтому я снова и снова вынужден проектировать списки в виде элементов-ссылок обычного int[]-массива индексов, требующих 4 байта на узел. Или писать функции для динамического увеличения размера массива

Вы уже не первый раз жалуетесь, что в Java нет каких-то хитроумных списков с полями int. И заметьте, никому кроме вас эти списки не нужны. Дык написали бы уже давно свою библиотеку - работы то на два дня - и пользовались на здоровие. Зачем же это в Java ради вас одного добавлять эти функции?

Мне например не хватало функции join из перла, или IFNULL из MS-SQL, или empty из PHP. Так я их уже много лет назад написал и сижу довольный :-)

спустя 51 минуту [обр] Даниэль Алиевский(35/125)[досье]

30-ый[досье] Насчет TreeSet/TreeMap понял. Фактически Вы используете их для сортировки. Наверно, неплохо, но по логике это ведь не их предназначение. Для сортировки (объектов) есть класс Arrays. Могли бы быть и методы, позволяющие выполнять сортировку удобно, скажем, метод sort(Comparator) у класса ArrayList.

Хорошо ли, что SortedSet/SortedMap побуждают использовать взвешенные деревья не по назначению? Взвешенное дерево нужно, чтобы можно было за логарифмическое время добавить или удалить элемент из уже отсортированной структуры. Операция алгоритмически, конечно, важная - но для специальных задач, когда в действительности нужна обширная специализированная библиотека с множеством сортировочных алгоритмов и структур данных. Использовать подобное дерево, чтобы просто отсортировать вектор - не эффективно ни по памяти (для многих реализаций, не знаю насчет Sun-овской), ни по времени.

Как использовать LinkedList достаточно внятно сказано в документации:

Внятно, но, скажем мягко, в расчете на уровень дилетантов. Строить очередь, стек или дек на основе связного списка - это интересно разве что для обучения студента. Ибо менее эффективную и менее надежную реализацию сложно придумать. Списки, вообще, требуют крайней аккуратности: неверная ссылка или неверный порядок коррекции ссылок может привести к чрезвычайно неприятным ошибкам. Стек легче всего делается на векторе (ArrayList или просто массив). То же относится к очередям и декам, если их длина заведомо не превосходит некоторого предела. Если же она не ограничена, то как раз разумнее было бы сделать соответствующие библиотечные классы, основанные на массиве, с переотведением памяти при необходимости, и обеспечить, как вариант, произвольный доступ к любому элементу очереди/дека, что при списочной реализации получается очень неэффективено.

Что же касается альтернативных объектов из 1.1, так Sun вроде недвусмысленно намекает, что новые объекты по причине отказа от потоко-безопасности работают быстрее. Т.к. программы на Java часто на половину состоят из работы с коллекциями, я не вижу причин терять дополнительную производительность на обеспечении излишней потокобезопасности.

Я, видимо, недостаточно ясно высказался. Конечно, я согласен, что List/ArrayList и HashMap разумнее Vector/Hashtable. Но я говорю, что лишь эти коллекции - имеющие чуть менее совершенные эквиваленты в Java 1.1 - действительно кажутся мне полезными. Т.е. что Java 1.2 привнесла очень много "лишнего" (за исключением Swing), вместо того, чтобы просто исправить глупости первых версий. И что из-за этого "лишнего" теперь возникли generics, а с ними язык из простого и ясного превратился в заумного монстра, способного конкурировать нетривиальностью с Perl. Я, конечно, преувеличиваю, но идея понятна :) Неужели вас вдохновляет конструкция class Enum<E extends Enum<E>>? Лично мне не хватило энтузиазма разбираться, почему это правильно :)

Вы уже не первый раз жалуетесь, что в Java нет каких-то хитроумных списков с полями int. И заметьте, никому кроме вас эти списки не нужны. Дык написали бы уже давно свою библиотеку - работы то на два дня - и пользовались на здоровие. Зачем же это в Java ради вас одного добавлять эти функции?

Понятно, что написал, и даже не одну, а целую кучу. В этом и проблема - собственные библиотеки всегда надо поддерживать, документировать, обучать им, привыкать, подключать, в то время как стандартные используются всеми "без вопросов". К тому же работы тут не на два дня, а, рискну предположить, на много месяцев, желательно с обсуждением многими программистами и длительным тестированием на надежность, удобство, полноту и прочее. Если, конечно, хочется получить нечто столь же продуманное, как у компании Sun, которая делает бизнес на изготовлении своих библиотек.

А что "кроме меня никому не нужны" - в этом я не уверен. В алгоритмике без этого никак: RAM и процессор обычно используются по полной программе, и всегда отводить по 20 байт вместо 4 совершенно непозволительно. А для неалгоритмических приложений, повторю свое мнение, никаких коллекций и не надо, кроме банального хэша и вектора переменной длины (присутствующих, кстати, в любом скриптовом языке уже на языковом уровне).

Powered by POEM™ Engine Copyright © 2002-2005