Колекції (Collections) в Java. Вступ

Ця стаття є першою з серії статей про колекції в Java. У майбутніх статтях буде розглянуто основні класи-колекції, що з'явилися в Java 1.5. Будуть розглянуті класи, успадковані від Set, List, Queue та Map: ArrayList, HashSet, EnumSet, LinkedHashSet, LinkedList, PriorityQueue, TreeSet, HashMap, LinkedHashMap, TreeMap та інші.

Трохи історії

До появи версії 1.5 в Java були тільки 3 типи колекцій: масиви, Vector (і успадкований від нього Stack) і Hashtable.

До Java 1.4 включно Vector представляв собою чергу, в яку можна було додавати об'єкт будь-якого класу. Він представляв простий спосіб роботи з ланцюжком елементів. Так як типізовані колекції з'явилися тільки в 5-й версії Java, то програмісти нерідко використовували Vector для зберігання об'єктів різних класів через простоту використання. Звичайно, і в 5-й версії Java, можна створити колекцію, яка буде зберігати об'єкти класу java.lang.Object, але це робити строго не рекомендується. В Java 1.5 Vector став типізований як і інші класи колекцій.

Hashtable - колекція, що дозволяє зберігати дані у вигляді ключ-значення. Іноді Hashtable порівнюють (і прирівнюють) з асоціативними масивами з інших мов програмування. Ключ і значення можуть бути будь-яким об'єктом, але не примітивом. Також, ключ в Hashtable не може бути null.

До Java 1.4 в Vector і Hashtable не можна було додавати примітивні типи, такі як: int, float, long, double. Для створення списку примітивних об'єктів необхідно було використовувати оболонки для примітивних типів: Integer, Float, Long, Double. З виходом Java версії 1.5, в Vector і Hashtable можна додавати примітивні типи. Вони будуть автоматично перетворені в свої обгортки.

Vector і Hashtable були і залишаються синхронізованими, внаслідок чого операції з ними займають більше часу, ніж з аналогічними класами List і Map. Vector і Hashtable - застарілі класи, які не рекомендується використовувати.

Колекції в Java 1.5

Перейдемо безпосередньо до колекцій, які з'явилися в Java 1.5. Всі колекції успадковані від одного інтерфейсу Collection з пакету java.util. Інтерфейс Collection, в свою чергу, реалізує інтерфейс Iterable. Це означає, що всі класи, успадковані від Collection можуть використовуватися в циклі foreach. Наприклад так:

List<String> stringList = Arrays.asList("1", "2", "4", "3");
for( String entry : stringList ){
	System.out.println( entry );
}

Врахуйте, що видалення елементів з колекції в циклі foreach небезпечно. Для цих цілей використовуйте ітератор, наприклад так:

for (Iterator<?> it = c.iterator(); it.hasNext(); )
	if (!cond(it.next()))
		it.remove();

Ієрархія інтерфейсів, успадкованих від Collection представлена ​​на Рис.1. Як можна помітити, відсутній інтерфейс Map - він не успадкований від Collection і про нього розмова буде окрема.

Рис 1. Колекції (Collections) в Java

Варто зауважити, що в Java немає жодного класу, який безпосередньо реалізує інтерфейс Collection. Це відбувається через проміжні інтерфейси List, Set і Queue.

Загальноприйняті правила використання Collection

1. Завжди коректно описуйте методи equals() і hashCode() в об'єктах, які будуть додані до колекції. Наприклад, для того, щоб метод contains (Object o) повернув коректне значення, необхідно щоб виконувалася наступна умова: (o == null ? e == null: o.equals(e)). Метод hashCode() гарантує, що два об'єкти з різними значеннями hashCode() не можуть бути рівні. Також метод hashCode() може використовуватися колекцією для найбільш ефективного розміщення об'єктів в пам'яті. Це правило не стосується стандартних типів, таких як String, Integer, Float і т.д. так як в цих класах вже реалізовані обидва методи.

2. Кожен клас, який реалізує інтерфейс Collection, має як мінімум два конструктора: конструктор за замовчуванням і конструктор, що приймає колекцію (об'єкт Collection). Це правило лягає на плечі програміста так як у інтерфейсів не може бути конструкторів. приклад:

List<String> stringList = Arrays.asList( "2", "1", "2", "4", "3");
Set<String> stringSet = new HashSet<String>( stringList );
for( String entry : stringSet ){
	System.out.print( entry );
}
// Output: 3214

3. Клас реалізує інтерфейс Collection і якщо метод не підтримується колекцією, то необхідно генерувати помилку UnsupportedOperationException. Це є необов'язковим правилом. Наприклад, якщо колекція не може бути модифікована, то при виклику методу add() може відбутися виключення UnsupportedOperationException, а може і не відбутися якщо це не критично.

Основні переваги використання колекцій

• Знижує кількість написаного коду. Надаючи корисну структуру даних і алгоритмів, колекції звільняють від низькорівневого програмування і дозволяють зосередиться на інших частинах програми.
• Підвищує швидкодію і якість програми. Колекції забезпечують високу продуктивність, високу якість реалізації корисних структур даних і алгоритмів. Різні реалізації кожного інтерфейсу є взаємозамінними, так що програми можуть бути легко налаштовані на перемикання різних реалізацій колекцій.
• Дозволяє взаємодіяти не пов'язаним між собою API. Колекції загальновживані, тому можуть легко використовуватися в якості аргументів функцій та їх значень, що повертаються функціями.
• Зменшує кількість зусиль, прикладених для вивчення нових API. Багато API отримують колекції на вхід і віддають інші колекції на виході. У недавньому минулому кожне API мало свою власну реалізацію своїх колекцій. Через це доводилося вивчати структури даних, властиві кожному API.
• Зменшує кількість зусиль, прикладених для розробки нових API. Це зворотна сторона попередньої переваги. Програмістам немає необхідності створювати власні колекції, досить використовувати наявні або реалізувати свої на основі існуючих інтерфейсів.
• Сприяє повторному використанню програмного забезпечення. Нові структури даних, успадковані від існуючих реалізацій колекцій або інтерфейсів колекцій, легко можуть бути використані де-завгодно.