JEP 431 добавил в Java то, чего не хватало с самого начала, а именно единый интерфейс для упорядоченных коллекций. Разберем, что изменилось под капотом.
🔹 Проблема, которую игнорировали
До Java 21 List и Deque имеют порядок обхода, но их общий суперинтерфейс Collection - нет. Set не гарантирует порядок, но LinkedHashSet и SortedSet — гарантируют. Единого API для "дай первый/последний элемент" или "обход в обратном порядке" не существовало.
Результат? Костыли:
// До Java 21
list.get(0) // List
deque.getFirst() // Deque
sortedSet.first() // SortedSet
linkedHashSet.iterator().next() // LinkedHashSet
🔹 Три новых интерфейса
JEP 431 внедрил в иерархию коллекций три интерфейса:
interface SequencedCollection<E> extends Collection<E> {
SequencedCollection<E> reversed();
void addFirst(E);
void addLast(E);
E getFirst();
E getLast();
E removeFirst();
E removeLast();
}
interface SequencedSet<E> extends SequencedCollection<E>, Set<E> {
SequencedSet<E> reversed();
}
interface SequencedMap<K,V> extends Map<K,V> {
SequencedMap<K,V> reversed();
Map.Entry<K,V> firstEntry();
Map.Entry<K,V> lastEntry();
Map.Entry<K,V> pollFirstEntry();
Map.Entry<K,V> pollLastEntry();
// ... и другие методы
}
Все методы (кроме reversed()) - это default методы, промоутнутые из Deque. Это обеспечило обратную совместимость.
▪️ Важнейший нюанс: reversed() возвращает view, а не копию.
Изменения в оригинале видны в reversed view. Под капотом это lightweight wrapper, который инвертирует индексы при обращении.
🔹 Интеграция в иерархию
Collection<E>
└─ SequencedCollection<E>
├─ List<E>
├─ Deque<E>
└─ Set<E>
└─ SequencedSet<E>
└─ SortedSet<E>
└─ NavigableSet<E>
Map<K,V>
└─ SequencedMap<K,V>
└─ SortedMap<K,V>
└─ NavigableMap<K,V>
🔹 SortedSet и SortedMap
SortedSet и SortedMap теперь имплементируют sequenced интерфейсы, но есть нюанс: методы addFirst()/addLast()/putFirst()/putLast() существуют лишь для того, чтобы бросить UnsupportedOperationException.
Liskov Substitution Principle: "Am I a joke to you?"
Но справедливости ради — Java Collections делает так уже давно:
— map.keySet().add() → UnsupportedOperationException
— Arrays.asList().add() → UnsupportedOperationException
— Collections.unmodifiableList().set() → UnsupportedOperationException
Это называется optional operations — когда методы есть, но работать не обязаны. Документация прямо говорит:
Many methods will throw UnsupportedOperationException if the operation cannot be performed.
Альтернативы были хуже: либо создавать зоопарк из ReadOnlySequencedSet, MutableSequencedSet, PartiallyMutableSequencedSet, либо оставить SortedSet за бортом единообразного API.
#CoreJava
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥4❤2
Чистый, масштабируемый и поддерживаемый код — не просто идеал, а необходимость. SOLID помогает писать архитектуру, которая выдерживает рост и изменения без боли 👇
🧩 Каждый класс отвечает за что-то одно.
📍 Пример: Employee хранит данные сотрудника, но не считает зарплату — этим занимается PayrollService.
🧱 Класс открыт для расширения, но закрыт для изменения.
📍 Пример: интерфейс Shape с методом calculateArea().
Новые фигуры (Circle, Rectangle) добавляются без правки существующего кода.
🦆 Подкласс должен полностью заменять родителя, не ломая логику.
📍 Пример: если Bird умеет fly(), то Sparrow должен уметь летать.
Но Penguin не должен наследовать fly() — нарушает LSP.
🔌 Не заставляй клиентов реализовывать лишние методы.
📍 Пример: вместо интерфейса Worker с work() и eat(),
разделите его на Workable и Eatable.
Робот реализует только Workable, человек — оба.
⚙️ Зависим от абстракций, а не от реализаций.
📍 Пример: Switch работает с интерфейсом Switchable.
Ему всё равно, включает ли он лампу (LightBulb) или вентилятор (Fan).
💡 Освоив SOLID, вы начнёте проектировать системы,
которые не боятся изменений и масштабируются без боли.
#CoreJava
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥4❤1