Почему некоторые библиотеки определяют свои собственные коллекции?

Question

Например, в Jsoup они определили класс Elements для сбора элементов.

Обычно определяют класс A и As, который содержит много A (s).).Но почему?Почему бы нам просто не использовать ArrayList или что-то еще?

Answer 1

В этом особом примере, глядя на API , показано, что в дополнение к обычным методам сбора, Elements предоставляет связанные с обработкой HTML.Отсюда и реализация собственной коллекции.Кроме того, вы заметите, что Elements реализует Iterable, Collection и List.

Answer 2

Класс Elements в JSoup имеет много специфических методов для своей функции, например,

toggleClass(String className) 
html()

Который не будет доступен в ArrayList. Я думаю, ArrayList можно было бы расширить, но автор Elements пошел на композицию. Elements HAS-A ArrayList экземпляр, который он хранит в тайне. Elements предоставляет методы интерфейса List, специальные методы и др.

Но Elements поддерживается ArrayList - таким образом, автор может также декорировать методы ArrayList, которые он выберет для обнародования через свой собственный класс. Это выдержка из исходного кода:

  private List<Element> contents;

    public Elements() {
        contents = new ArrayList<Element>();
    }

Кстати: раньше вы видели оболочки до Java 5, чтобы обеспечить безопасность типов для Java Collections, но начиная с Java 5 Generics прекратили многое из этого.

Answer 3

Другая причина заключается в том, чтобы вводить специфичные для домена сущности. Это означает, например, что да, Elements это просто список, может быть реализован как ArrayList. Итак, через весь код, который вы видите ArrayList, который содержит Element. При чтении кода это не так легко прочитать. Но если я вижу тип Elements, я знаю, что программа говорит о коллекции Element, потому что домен JSoup - это HTML-документы, сделанные из элементов ...

Answer 4

Существует три основных причины создания пользовательского контейнера:

• Доступным контейнерам не хватает требуемой функциональности.
• Производительность доступных контейнеров не соответствует потребностям.
• Код должен минимизировать внешние зависимости.

Я не знаю, какая из них (если есть) применима к вашему примеру.Я бы не назвал зависимость от ArrayList как external , но, например, в C ++ это может быть допустимо, не полагаясь на контейнеры из стандартной библиотеки C ++ по этой причине.

Answer 5

Полагаю, это из-за того, что код написан для java 1.4 и ниже: в настоящее время не было возможности использовать обобщенные значения, такие как ArrayList<String>, для безопасных типов коллекций.

Answer 6

Просто ответ, который немного отличается от других:

Для некоторых библиотек, таких как KryoNet, необходима тщательная оптимизация (т.е. запрещение пустых ключей и значений, блокировка ключей и значений для определенного типа), чтобы можно было идентифицировать конкретное использование класса коллекции. Лучший способ сделать это - через расширение, поскольку это означает, что карта Class->ClassOptimisation, например, работает нормально. В противном случае вы получите массу экземпляров классов, оптимизируемых особыми способами, которые вам не нужны.

Answer 7

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

Answer 8

Ну, стандартные наборы делают свое дело для многих пользовательских случаев, но иногда нам нужны расширенные функции, различные характеристики производительности и тому подобное. Структуры данных являются важной темой в области компьютерных наук, и люди постоянно получают свои кандидатские диссертации. Даже для обычных пользователей существует множество библиотек, которые пытаются улучшить стандартные коллекции. Яркими примерами являются Google Guava и Apache Collections

Answer 9

Скорее всего, интерфейс List (или любой другой интерфейс коллекции) не соответствует их потребностям.Авторы могут захотеть иметь специализированные методы, которые делают вещи, которые интерфейс коллекции не позволяет.

Если вы посмотрите достаточно близко , вы увидите, что Elements infact реализует List<Element>.