Какова потребность платформы набора в Java?

Несколько причин:

• Классы коллекций Java предоставляют интерфейс более высокого уровня, чем массивы.
• Массивы имеют фиксированный размер. Коллекции (см. ArrayList) имеют гибкий размер.
• Эффективная реализация сложных структур данных (например, хеш-таблиц) поверх необработанных массивов является сложной задачей. Стандартный HashMap предоставляет вам это бесплатно.
• Существуют разные реализации, которые вы можете выбрать для одного и того же набора сервисов: ArrayList против LinkedList, HashMap против TreeMap, synchronized и т. Д.
• Наконец, массивы допускают ковариацию: установка элемента массива не гарантируется чтобы добиться успеха из-за ошибок ввода, которые можно обнаружить только во время выполнения. Дженерики предотвращают эту проблему в массивах.

Взгляните на этот фрагмент, который иллюстрирует проблему ковариации:

  String[] strings = new String[10];
  Object[] objects = strings;

  objects[0] = new Date();  // <- ArrayStoreException: java.util.Date

Реализации классов коллекций, таких как Set, List и Map, ближе к «проблемному пространству». Они позволяют разработчикам быстрее выполнять работу и превращать код в более читаемый / поддерживаемый.

Это зависит от потребностей вашего приложения. Существует очень много типов коллекций, включая:

• HashSet
• ArrayList
• HashMap
• TreeSet
• TreeMap
• LinkedList

Например, если вам нужно хранить пары ключ/значение, вам придется написать много пользовательского кода, если он будет основан на массиве - в то время как коллекции Hash* должны просто работать из коробки. Как всегда, выбирайте правильный инструмент для работы.

Массивы не всегда эффективны. Что, если вам нужно что-то вроде LinkedList ? Похоже, вам нужно изучить некоторую структуру данных: http://en.wikipedia.org/wiki/List_of_data_structures

Для каждого класса в Collections API есть свой ответ на ваш вопрос. Вот несколько примеров.

LinkedList: Если вы удаляете элемент из середины массива, вы оплачиваете стоимость перемещения всех элементов вправо от удаленного элемента. Не так со связанным списком.

Set: Если вы пытаетесь реализовать набор с массивом, добавление элемента или проверка наличия элемента выполняется за O (N). С HashSet это O (1).

Карта: реализация карты с использованием массива даст те же характеристики производительности, что и ваша предполагаемая реализация набора в виде массива.

Что ж, основная посылка "неверна" поскольку Java включала класс Dictionary, поскольку до того, как в языке существовали интерфейсы ...

коллекции предлагают списки, которые в некоторой степени похожи на массивы, но они предлагают гораздо больше вещей, которых нет. Я предполагаю, что вы только что говорили о List (и даже Set) и не упоминали Map.

Да, можно получить ту же функциональность, что и List и Set с массивом, однако это требует большой работы. Весь смысл библиотеки в том, что пользователям не нужно «катить свои собственные» реализации обычных вещей.

Если у вас есть единая реализация, которую используют все, будет легче оправдать затраты ресурсов на ее оптимизацию. Это означает, что при ускорении стандартных коллекций или сокращении объема используемой памяти все приложения, использующие их, получают улучшения бесплатно.

Единый интерфейс для каждой вещи также упрощает процесс обучения каждого разработчика - не существует множества различных способов сделать одно и то же.

Если бы вы хотели иметь растущий со временем массив, вы, вероятно, не стали бы размещать код роста по всем классам, а вместо этого написали бы один служебный метод для этого. То же самое для удаления и вставки и т. Д.

Кроме того, массивы не очень подходят для вставки / удаления, особенно когда вы ожидаете, что член .length должен отражать фактическое количество содержимого, поэтому вы потратите огромную сумму времени роста и сжатия массива. Массивы также не подходят для наборов, поскольку вам придется перебирать весь массив каждый раз, когда вы хотите выполнить вставку для проверки дубликатов. Это убило бы любую предполагаемую эффективность.