Обновлено и немного переделано оглавление! 👏
Добавлен план изучения Java который будет дополняться далее.
Если интересна информация ранее опубликованная на канале - пользуйтесь!😎
Добавлен план изучения Java который будет дополняться далее.
Если интересна информация ранее опубликованная на канале - пользуйтесь!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
История IT-технологий сегодня — 10 ноября
ℹ️ Кто родился в этот день
Здзислав И. Павляк (10 ноября 1926 г. — 7 апреля 2006 г.) — польский математик и информатик, основатель польской школы искусственного интеллекта; известен работами по теории приблизительных множеств (rough sets) и формализации знаний.
🌐 Знаковые события
1970 — Советский Союз запускает научную космическую станцию «Луна-17», которая через неделю прилунится в районе Моря Дождей. На поверхность спутника Земли выедет первое самоходное устройство «Луноход-1», которое будет управляться с Земли и путешествовать по лунной поверхности 11 месяцев.
1983 — на семинаре по компьютерной безопасности Фред Коэн представляет первый компьютерный вирус.
#Biography #Birth_Date #Events #10Ноября
Здзислав И. Павляк (10 ноября 1926 г. — 7 апреля 2006 г.) — польский математик и информатик, основатель польской школы искусственного интеллекта; известен работами по теории приблизительных множеств (rough sets) и формализации знаний.
1970 — Советский Союз запускает научную космическую станцию «Луна-17», которая через неделю прилунится в районе Моря Дождей. На поверхность спутника Земли выедет первое самоходное устройство «Луноход-1», которое будет управляться с Земли и путешествовать по лунной поверхности 11 месяцев.
1983 — на семинаре по компьютерной безопасности Фред Коэн представляет первый компьютерный вирус.
#Biography #Birth_Date #Events #10Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Вы еще читаете этот канал?
Anonymous Poll
59%
Да! Ежедневно!
33%
Иногда...
8%
Какой канал? Что я тут делаю?
Раздел 6. Коллекции в Java
Глава 5. Map — отображения (словари)
Основные методы: remove - глубокое погружение в механизм удаления элементов
Удаление элемента из Map — это не просто стирание данных, а комплексный процесс, направленный на сохранение структурной целостности коллекции и обеспечение эффективности последующих операций. Каждая реализация Map подходит к этому процессу со своей уникальной стратегией, отражающей ее внутреннее устройство и целевое назначение.
Общий алгоритм работы remove
Процесс выполнения метода remove(key) можно разделить на несколько взаимосвязанных фаз, каждая из которых вносит существенный вклад в общую корректность операции:
Фаза поиска и идентификации:
Валидация ключа и проверка его соответствия требованиям реализации
Локализация элемента в структуре данных с использованием механизмов, специфичных для типа Map
Подтверждение существования элемента и его идентификация
Фаза изоляции и отсоединения:
Разрыв связей между удаляемым элементом и остальной структурой
Сохранение ссылок на соседние элементы для последующего восстановления связей
Обработка специальных случаев (удаление корневого элемента, единственного элемента и т.д.)
Фаза реструктуризации и очистки:
Восстановление структурной целостности коллекции
Балансировка или реорганизация внутренней структуры
Освобождение ресурсов и обновление метаданных коллекции
Детальный разбор для HashMap
Процесс локализации элемента
Удаление в HashMap начинается с того же процесса, что и поиск — вычисления хэш-кода ключа и определения индекса бакета. Однако на этом сходство заканчивается. После локализации целевого бакета система должна не только найти удаляемый элемент, но и корректно извлечь его из цепочки коллизий, сохранив при этом связи между оставшимися элементами.
Удаление из цепочки коллизий
В зависимости от структуры и положения удаляемого элемента в цепочке, процесс может принимать различные формы:
Удаление единственного элемента из бакета: Самый простой случай — бакет просто обнуляется, освобождая место для будущих элементов.
Удаление первого элемента из связного списка: Голова списка перемещается на следующий элемент, а ссылки соответствующим образом обновляются.
Удаление элемента из середины списка: Требуется перекидывание ссылки предыдущего элемента на следующий, эффективно "вырезая" удаляемый узел из цепочки.
Удаление последнего элемента списка: У предыдущего элемента обнуляется ссылка на следующий элемент.
Специфика работы с деревьями
В современных версиях HashMap при работе с длинными цепочками коллизий, преобразованными в красно-черные деревья, процесс удаления значительно усложняется:
Поиск удаляемого узла: Выполняется стандартный поиск в бинарном дереве с учетом порядка ключей.
Удаление узла из дерева: В зависимости от положения узла (лист, узел с одним потомком, узел с двумя потомками) применяются различные стратегии извлечения.
Балансировка дерева: После удаления выполняется комплексная процедура перебалансировки дерева, включающая перекрашивание узлов и выполнение вращений для восстановления свойств красно-черного дерева.
Обратное преобразование: Если после удаления количество элементов в дереве падает ниже определенного порога, дерево может быть преобразовано обратно в связный список для экономии памяти.
Обновление метаданных и учетных данных
После успешного удаления элемента HashMap выполняет ряд важных служебных операций:
Уменьшение счетчика размера коллекции
Инкрементация счетчика модификаций (modCount) для поддержки fail-fast итераторов
Проверка необходимости обратного преобразования структур данных
Обновление статистики использования для потенциальной оптимизации
#Java #для_новичков #beginner #Map #remove
Глава 5. Map — отображения (словари)
Основные методы: remove - глубокое погружение в механизм удаления элементов
Удаление элемента из Map — это не просто стирание данных, а комплексный процесс, направленный на сохранение структурной целостности коллекции и обеспечение эффективности последующих операций. Каждая реализация Map подходит к этому процессу со своей уникальной стратегией, отражающей ее внутреннее устройство и целевое назначение.
Общий алгоритм работы remove
Процесс выполнения метода remove(key) можно разделить на несколько взаимосвязанных фаз, каждая из которых вносит существенный вклад в общую корректность операции:
Фаза поиска и идентификации:
Валидация ключа и проверка его соответствия требованиям реализации
Локализация элемента в структуре данных с использованием механизмов, специфичных для типа Map
Подтверждение существования элемента и его идентификация
Фаза изоляции и отсоединения:
Разрыв связей между удаляемым элементом и остальной структурой
Сохранение ссылок на соседние элементы для последующего восстановления связей
Обработка специальных случаев (удаление корневого элемента, единственного элемента и т.д.)
Фаза реструктуризации и очистки:
Восстановление структурной целостности коллекции
Балансировка или реорганизация внутренней структуры
Освобождение ресурсов и обновление метаданных коллекции
Детальный разбор для HashMap
Процесс локализации элемента
Удаление в HashMap начинается с того же процесса, что и поиск — вычисления хэш-кода ключа и определения индекса бакета. Однако на этом сходство заканчивается. После локализации целевого бакета система должна не только найти удаляемый элемент, но и корректно извлечь его из цепочки коллизий, сохранив при этом связи между оставшимися элементами.
Удаление из цепочки коллизий
В зависимости от структуры и положения удаляемого элемента в цепочке, процесс может принимать различные формы:
Удаление единственного элемента из бакета: Самый простой случай — бакет просто обнуляется, освобождая место для будущих элементов.
Удаление первого элемента из связного списка: Голова списка перемещается на следующий элемент, а ссылки соответствующим образом обновляются.
Удаление элемента из середины списка: Требуется перекидывание ссылки предыдущего элемента на следующий, эффективно "вырезая" удаляемый узел из цепочки.
Удаление последнего элемента списка: У предыдущего элемента обнуляется ссылка на следующий элемент.
Специфика работы с деревьями
В современных версиях HashMap при работе с длинными цепочками коллизий, преобразованными в красно-черные деревья, процесс удаления значительно усложняется:
Поиск удаляемого узла: Выполняется стандартный поиск в бинарном дереве с учетом порядка ключей.
Удаление узла из дерева: В зависимости от положения узла (лист, узел с одним потомком, узел с двумя потомками) применяются различные стратегии извлечения.
Балансировка дерева: После удаления выполняется комплексная процедура перебалансировки дерева, включающая перекрашивание узлов и выполнение вращений для восстановления свойств красно-черного дерева.
Обратное преобразование: Если после удаления количество элементов в дереве падает ниже определенного порога, дерево может быть преобразовано обратно в связный список для экономии памяти.
Обновление метаданных и учетных данных
После успешного удаления элемента HashMap выполняет ряд важных служебных операций:
Уменьшение счетчика размера коллекции
Инкрементация счетчика модификаций (modCount) для поддержки fail-fast итераторов
Проверка необходимости обратного преобразования структур данных
Обновление статистики использования для потенциальной оптимизации
#Java #для_новичков #beginner #Map #remove
👍1
Особенности LinkedHashMap
В LinkedHashMap операция удаления наследует всю сложность HashMap, но добавляет дополнительный слой — поддержание целостности двусвязного списка, отвечающего за порядок элементов.
Поддержание порядка доступа
При удалении элемента из LinkedHashMap происходит не только его извлечение из хэш-таблицы, но и корректное удаление из двусвязного списка:
Разрыв связей: Удаляемый элемент имеет ссылки на предыдущий и следующий элементы в списке порядка. Эти связи должны быть аккуратно разорваны.
Обновление соседей: Соседние элементы получают новые ссылки друг на друга, эффективно закрывая образовавшуюся брешь.
Корректировка границ: Если удаляемый элемент был головой или хвостом списка, соответствующие ссылки в самом LinkedHashMap обновляются.
Обработка callback-событий
LinkedHashMap предоставляет механизм обратных вызовов, которые срабатывают во время операции удаления:
Этот механизм позволяет подклассам реагировать на события удаления и выполнять дополнительную логику, такую как обновление внешних структур данных или ведение статистики.
Специфика TreeMap
В TreeMap операция удаления является одной из наиболее сложных среди всех реализаций Map, поскольку требует поддержания строгих свойств красно-черного дерева.
Алгоритм удаления из бинарного дерева поиска
Процесс удаления в TreeMap следует классическому алгоритму удаления из бинарного дерева поиска с последующей балансировкой:
Поиск удаляемого узла: Стандартный обход дерева от корня к целевому узлу с сравнением ключей.
Классификация случая удаления: В зависимости от количества потомков удаляемого узла применяются различные стратегии:
Узел без потомков (лист): Простое удаление без дополнительных операций
Узел с одним потомком: Потомок "поднимается" на место удаляемого узла
Узел с двумя потомками: Поиск преемника (наименьшего элемента в правом поддереве) и замена удаляемого узла на преемника
Балансировка красно-черного дерева
После физического удаления узла выполняется сложная процедура балансировки для восстановления свойств красно-черного дерева:
Анализ цветовой ситуации: Определение типа нарушения свойств дерева после удаления.
Применение алгоритмов перебалансировки
В зависимости от конкретной ситуации могут применяться различные комбинации перекрашиваний и вращений:
Левое вращение
Правое вращение
Смена цвета узлов
Комбинированные операции
Гарантии сбалансированности: Процесс балансировки гарантирует, что дерево остается сбалансированным, обеспечивая логарифмическую производительность для последующих операций.
Обработка специальных случаев
Удаление корневого узла: Требует особой осторожности, так как корень является точкой входа во все дерево.
Удаление из пустого дерева: Должно корректно обрабатываться без возникновения исключений.
Удаление несуществующего элемента: Должно завершаться корректно с возвратом null.
#Java #для_новичков #beginner #Map #remove
В LinkedHashMap операция удаления наследует всю сложность HashMap, но добавляет дополнительный слой — поддержание целостности двусвязного списка, отвечающего за порядок элементов.
Поддержание порядка доступа
При удалении элемента из LinkedHashMap происходит не только его извлечение из хэш-таблицы, но и корректное удаление из двусвязного списка:
Разрыв связей: Удаляемый элемент имеет ссылки на предыдущий и следующий элементы в списке порядка. Эти связи должны быть аккуратно разорваны.
Обновление соседей: Соседние элементы получают новые ссылки друг на друга, эффективно закрывая образовавшуюся брешь.
Корректировка границ: Если удаляемый элемент был головой или хвостом списка, соответствующие ссылки в самом LinkedHashMap обновляются.
Обработка callback-событий
LinkedHashMap предоставляет механизм обратных вызовов, которые срабатывают во время операции удаления:
void afterNodeRemoval(Node<K,V> e) // вызывается после физического удаления узла
Этот механизм позволяет подклассам реагировать на события удаления и выполнять дополнительную логику, такую как обновление внешних структур данных или ведение статистики.
Специфика TreeMap
В TreeMap операция удаления является одной из наиболее сложных среди всех реализаций Map, поскольку требует поддержания строгих свойств красно-черного дерева.
Алгоритм удаления из бинарного дерева поиска
Процесс удаления в TreeMap следует классическому алгоритму удаления из бинарного дерева поиска с последующей балансировкой:
Поиск удаляемого узла: Стандартный обход дерева от корня к целевому узлу с сравнением ключей.
Классификация случая удаления: В зависимости от количества потомков удаляемого узла применяются различные стратегии:
Узел без потомков (лист): Простое удаление без дополнительных операций
Узел с одним потомком: Потомок "поднимается" на место удаляемого узла
Узел с двумя потомками: Поиск преемника (наименьшего элемента в правом поддереве) и замена удаляемого узла на преемника
Балансировка красно-черного дерева
После физического удаления узла выполняется сложная процедура балансировки для восстановления свойств красно-черного дерева:
Анализ цветовой ситуации: Определение типа нарушения свойств дерева после удаления.
Применение алгоритмов перебалансировки
В зависимости от конкретной ситуации могут применяться различные комбинации перекрашиваний и вращений:
Левое вращение
Правое вращение
Смена цвета узлов
Комбинированные операции
Гарантии сбалансированности: Процесс балансировки гарантирует, что дерево остается сбалансированным, обеспечивая логарифмическую производительность для последующих операций.
Обработка специальных случаев
Удаление корневого узла: Требует особой осторожности, так как корень является точкой входа во все дерево.
Удаление из пустого дерева: Должно корректно обрабатываться без возникновения исключений.
Удаление несуществующего элемента: Должно завершаться корректно с возвратом null.
#Java #для_новичков #beginner #Map #remove
👍1
Специализированные реализации
ConcurrentHashMap
В ConcurrentHashMap операция удаления оптимизирована для многопоточного доступа и требует особого подхода к синхронизации:
Сегментированная блокировка: В старых версиях блокируется только соответствующий сегмент, позволяя другим операциям продолжаться в других сегментах.
CAS-операции: В современных версиях используются compare-and-swap операции для атомарного обновления ссылок, минимизируя блокировки.
Гарантии памяти: Обеспечиваются строгие гарантии видимости изменений между потоками.
Координация с другими операциями: Сложные механизмы предотвращения гонок данных между concurrent операциями put, get и remove.
WeakHashMap
В WeakHashMap операция удаления тесно интегрирована с системой сборки мусора:
Автоматическое удаление: Элементы могут быть удалены автоматически при сборке мусора, если на ключи нет сильных ссылок.
Координация с ReferenceQueue: Система отслеживает уведомления от сборщика мусора о готовности к удалению.
Фоновая очистка: Периодическое выполнение процедуры очистки для удаления "умерших" записей.
Обработка особых случаев и edge cases
Удаление несуществующих элементов
Все реализации Map должны корректно обрабатывать попытку удаления несуществующего элемента:
Возврат null вместо выброса исключения
Отсутствие модификации структуры данных
Сохранение целостности коллекции
Удаление во время итерации
Особую сложность представляет удаление элементов во время обхода коллекции:
Fail-fast итераторы: Большинство реализаций используют механизм fail-fast, который обнаруживает структурные модификации во время итерации и выбрасывает ConcurrentModificationException.
Безопасные стратегии удаления: Использование Iterator.remove() для безопасного удаления во время итерации.
Специализированные итераторы: В ConcurrentHashMap итераторы designed для работы с concurrent модификациями.
Удаление null ключей
Разные реализации по-разному обрабатывают null ключи:
HashMap: Специальная обработка null ключа, хранящегося в бакете 0
TreeMap: Не поддерживает null ключи — выбрасывает исключение
ConcurrentHashMap: Не поддерживает null ключи из-за многопоточных ограничений
Влияние на производительность
Факторы, влияющие на стоимость операции remove
Положение элемента: В HashMap стоимость зависит от длины цепочки коллизий, в TreeMap — от глубины узла в дереве.
Структурные изменения: Необходимость балансировки или реорганизации значительно увеличивает стоимость операции.
Размер коллекции: В общем случае стоимость растет с размером коллекции, но характер роста зависит от реализации.
Сравнительная производительность
HashMap: O(1) в среднем случае, O(log n) при работе с деревьями коллизий
LinkedHashMap: O(1) с небольшими дополнительными затратами на обновление списка порядка
TreeMap: O(log n) в худшем случае благодаря сбалансированности дерева
ConcurrentHashMap: Сопоставимо с HashMap, но с дополнительными затратами на синхронизацию
Потокобезопасность и конкурентность
Проблемы многопоточного доступа
Состояние гонки: Конкурентные операции remove и put могут привести к потере данных или повреждению структуры.
Видимость изменений: Без proper синхронизации изменения, сделанные одним потоком, могут быть не видны другим потокам.
Повреждение структур данных: Неправильная синхронизация может привести к образованию циклов в связных списках или нарушению свойств деревьев.
Стратегии обеспечения потокобезопасности
Явная синхронизация: Использование synchronized блоков или locks для координации доступа.
Thread-safe реализации: Применение ConcurrentHashMap или Collections.synchronizedMap().
Иммутабельные коллекции: Создание новых коллекций вместо модификации существующих в многопоточной среде.
#Java #для_новичков #beginner #Map #remove
ConcurrentHashMap
В ConcurrentHashMap операция удаления оптимизирована для многопоточного доступа и требует особого подхода к синхронизации:
Сегментированная блокировка: В старых версиях блокируется только соответствующий сегмент, позволяя другим операциям продолжаться в других сегментах.
CAS-операции: В современных версиях используются compare-and-swap операции для атомарного обновления ссылок, минимизируя блокировки.
Гарантии памяти: Обеспечиваются строгие гарантии видимости изменений между потоками.
Координация с другими операциями: Сложные механизмы предотвращения гонок данных между concurrent операциями put, get и remove.
WeakHashMap
В WeakHashMap операция удаления тесно интегрирована с системой сборки мусора:
Автоматическое удаление: Элементы могут быть удалены автоматически при сборке мусора, если на ключи нет сильных ссылок.
Координация с ReferenceQueue: Система отслеживает уведомления от сборщика мусора о готовности к удалению.
Фоновая очистка: Периодическое выполнение процедуры очистки для удаления "умерших" записей.
Обработка особых случаев и edge cases
Удаление несуществующих элементов
Все реализации Map должны корректно обрабатывать попытку удаления несуществующего элемента:
Возврат null вместо выброса исключения
Отсутствие модификации структуры данных
Сохранение целостности коллекции
Удаление во время итерации
Особую сложность представляет удаление элементов во время обхода коллекции:
Fail-fast итераторы: Большинство реализаций используют механизм fail-fast, который обнаруживает структурные модификации во время итерации и выбрасывает ConcurrentModificationException.
Безопасные стратегии удаления: Использование Iterator.remove() для безопасного удаления во время итерации.
Специализированные итераторы: В ConcurrentHashMap итераторы designed для работы с concurrent модификациями.
Удаление null ключей
Разные реализации по-разному обрабатывают null ключи:
HashMap: Специальная обработка null ключа, хранящегося в бакете 0
TreeMap: Не поддерживает null ключи — выбрасывает исключение
ConcurrentHashMap: Не поддерживает null ключи из-за многопоточных ограничений
Влияние на производительность
Факторы, влияющие на стоимость операции remove
Положение элемента: В HashMap стоимость зависит от длины цепочки коллизий, в TreeMap — от глубины узла в дереве.
Структурные изменения: Необходимость балансировки или реорганизации значительно увеличивает стоимость операции.
Размер коллекции: В общем случае стоимость растет с размером коллекции, но характер роста зависит от реализации.
Сравнительная производительность
HashMap: O(1) в среднем случае, O(log n) при работе с деревьями коллизий
LinkedHashMap: O(1) с небольшими дополнительными затратами на обновление списка порядка
TreeMap: O(log n) в худшем случае благодаря сбалансированности дерева
ConcurrentHashMap: Сопоставимо с HashMap, но с дополнительными затратами на синхронизацию
Потокобезопасность и конкурентность
Проблемы многопоточного доступа
Состояние гонки: Конкурентные операции remove и put могут привести к потере данных или повреждению структуры.
Видимость изменений: Без proper синхронизации изменения, сделанные одним потоком, могут быть не видны другим потокам.
Повреждение структур данных: Неправильная синхронизация может привести к образованию циклов в связных списках или нарушению свойств деревьев.
Стратегии обеспечения потокобезопасности
Явная синхронизация: Использование synchronized блоков или locks для координации доступа.
Thread-safe реализации: Применение ConcurrentHashMap или Collections.synchronizedMap().
Иммутабельные коллекции: Создание новых коллекций вместо модификации существующих в многопоточной среде.
#Java #для_новичков #beginner #Map #remove
👍2
Что выведет код?
#Tasks
import java.util.HashMap;
import java.util.Map;
public class Task101125 {
public static void main(String[] args) {
Map<Integer, String> map = new HashMap<>();
map.put(1, "one");
map.put(2, "two");
map.put(3, "three");
String result1 = map.remove(2);
String result2 = map.remove(4);
boolean result3 = map.remove(1, "two");
boolean result4 = map.remove(3, "three");
System.out.println(result1);
System.out.println(result2);
System.out.println(result3);
System.out.println(result4);
}
}
#Tasks
Варианты ответа:
Anonymous Quiz
0%
two two true false
22%
two two false true
0%
two null true false
78%
two null false true
Вопрос с собеседований
Чем отличаются и в чем схожи @Component, @Service, @Repository, @Controller?🤓
Ответ:
Все аннотации — это стереотипы Spring-компонентов.
@Component — базовая аннотация.
@Service — для бизнес-логики.
@Repository — для DAO и перехвата исключений JDBC.
@Controller — для веб-слоя (обработка запросов).
#собеседование
Чем отличаются и в чем схожи @Component, @Service, @Repository, @Controller?
Ответ:
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Java for Beginner
Вы еще читаете этот канал?
Реально странно...
Из 750 человек на канале только 33 вообще отреагировало на пост, и только 20 читает канал постоянно...(((
А зачем остальные подписались? Боты? Вроде все живые люди))))
Как мне оживить канал, подскажите?
Из 750 человек на канале только 33 вообще отреагировало на пост, и только 20 читает канал постоянно...(((
А зачем остальные подписались? Боты? Вроде все живые люди))))
Как мне оживить канал, подскажите?
История IT-технологий сегодня — 11 ноября
ℹ️ Кто родился в этот день
Гевин Андресен (англ. Gavin Andresen, имя при рождении Гевин Белл, англ. Gavin Bell) — программист, ключевая фигура ранней разработки программного обеспечения для Bitcoin; после ухода Сатоши Нового он был фактическим ведущим разработчиком референсной реализации клиента.
🌐 Знаковые события
1572 — датский астроном Тихо Браге обнаруживает вспышку сверхновой звезды в созвездии Кассиопеи.
1983 — калифорнийский студент Фред Коэн успешно завершил курсовую работу по созданию прототипа первого компьютерного вируса — программы, которая была способна к саморазмножению и распространению по сетям.
#Biography #Birth_Date #Events #11Ноября
Гевин Андресен (англ. Gavin Andresen, имя при рождении Гевин Белл, англ. Gavin Bell) — программист, ключевая фигура ранней разработки программного обеспечения для Bitcoin; после ухода Сатоши Нового он был фактическим ведущим разработчиком референсной реализации клиента.
1572 — датский астроном Тихо Браге обнаруживает вспышку сверхновой звезды в созвездии Кассиопеи.
1983 — калифорнийский студент Фред Коэн успешно завершил курсовую работу по созданию прототипа первого компьютерного вируса — программы, которая была способна к саморазмножению и распространению по сетям.
#Biography #Birth_Date #Events #11Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1
Что такое GraphQL и зачем он появился
Почему REST перестал устраивать и как Facebook придумал альтернативу
Современные приложения всё чаще строятся вокруг API.
Клиентам — будь то браузеры, мобильные приложения или IoT-устройства — нужны данные с сервера.
Долгое время стандартом для этого был REST, но со временем его ограничения стали очевидны.
Именно в ответ на эти ограничения в 2012 году в Facebook родился GraphQL — язык запросов для API, который изменил способ взаимодействия клиента и сервера.
1. Почему REST перестал всем подходить
REST долгое время считался идеальным способом построения API: простые URL, понятные методы (GET, POST, PUT, DELETE), формат JSON, читаемость.
Но со временем приложения стали сложнее, особенно на фронтенде.
Проблема 1: избыточные данные (overfetching).
REST-эндпоинт /users/42 возвращает всю информацию о пользователе — даже если на экране нужно только имя и аватар.
Клиент не может сказать серверу: “дай только эти два поля”.
В итоге трафик растёт, запросы замедляются, особенно на мобильных устройствах.
Проблема 2: недостаток данных (underfetching).
Обратная ситуация — когда данных не хватает.
Например, чтобы показать пользователя вместе с его постами и комментариями, REST-клиенту придётся сделать три запроса: /users/42, /users/42/posts, /posts/{id}/comments.
Каждый запрос — это отдельное соединение, время, накладные расходы.
Проблема 3: разные клиенты — разные потребности.
Мобильное приложение хочет меньше данных (экономия трафика), веб-клиент — больше.
REST вынуждает сервер создавать несколько версий эндпоинтов:
/users, /users/details, /users/short, и всё это быстро превращается в хаос.
Проблема 4: сложная эволюция.
Добавление новых полей или изменение структуры часто ломает старых клиентов.
Нужны версии: /v1/users, /v2/users, /v3/users.
С ростом проекта версионность превращается в отдельную боль.
Все эти проблемы — прямое следствие того, что REST навязывает структуру данных с серверной стороны.
Клиент получает то, что сервер решил вернуть.
GraphQL переворачивает это с ног на голову.
2. История появления GraphQL
GraphQL был создан внутри Facebook в 2012 году, когда компания столкнулась с резким ростом мобильных клиентов.
REST больше не справлялся: каждое обновление приложения требовало всё больше запросов к серверу, а мобильный интернет не прощал лишних килобайт.
Команда Facebook решила, что сервер не должен диктовать, какие данные возвращать.
Вместо этого клиент должен описывать свои потребности декларативно — “мне нужны вот такие данные, вот в такой структуре”.
В 2015 году Facebook открыл исходный код GraphQL, и он быстро стал стандартом в индустрии.
Сегодня его используют GitHub, Shopify, Twitter, Netflix, Pinterest, Airbnb и тысячи других компаний.
3. Основная идея GraphQL
Главная концепция GraphQL проста, но революционна:
клиент сам определяет, какие данные ему нужны.
Клиент не делает серию запросов к разным ресурсам, как в REST.
Он отправляет один запрос на сервер с точным описанием нужных полей, а сервер возвращает данные в том же формате.
Пример запроса:
Ответ сервера:
Клиент получает ровно то, что запросил — ни байта больше, ни меньше.
Больше нет проблемы overfetching или underfetching.
#Java #middle #GraphQL
Почему REST перестал устраивать и как Facebook придумал альтернативу
Современные приложения всё чаще строятся вокруг API.
Клиентам — будь то браузеры, мобильные приложения или IoT-устройства — нужны данные с сервера.
Долгое время стандартом для этого был REST, но со временем его ограничения стали очевидны.
Именно в ответ на эти ограничения в 2012 году в Facebook родился GraphQL — язык запросов для API, который изменил способ взаимодействия клиента и сервера.
1. Почему REST перестал всем подходить
REST долгое время считался идеальным способом построения API: простые URL, понятные методы (GET, POST, PUT, DELETE), формат JSON, читаемость.
Но со временем приложения стали сложнее, особенно на фронтенде.
Проблема 1: избыточные данные (overfetching).
REST-эндпоинт /users/42 возвращает всю информацию о пользователе — даже если на экране нужно только имя и аватар.
Клиент не может сказать серверу: “дай только эти два поля”.
В итоге трафик растёт, запросы замедляются, особенно на мобильных устройствах.
Проблема 2: недостаток данных (underfetching).
Обратная ситуация — когда данных не хватает.
Например, чтобы показать пользователя вместе с его постами и комментариями, REST-клиенту придётся сделать три запроса: /users/42, /users/42/posts, /posts/{id}/comments.
Каждый запрос — это отдельное соединение, время, накладные расходы.
Проблема 3: разные клиенты — разные потребности.
Мобильное приложение хочет меньше данных (экономия трафика), веб-клиент — больше.
REST вынуждает сервер создавать несколько версий эндпоинтов:
/users, /users/details, /users/short, и всё это быстро превращается в хаос.
Проблема 4: сложная эволюция.
Добавление новых полей или изменение структуры часто ломает старых клиентов.
Нужны версии: /v1/users, /v2/users, /v3/users.
С ростом проекта версионность превращается в отдельную боль.
Все эти проблемы — прямое следствие того, что REST навязывает структуру данных с серверной стороны.
Клиент получает то, что сервер решил вернуть.
GraphQL переворачивает это с ног на голову.
2. История появления GraphQL
GraphQL был создан внутри Facebook в 2012 году, когда компания столкнулась с резким ростом мобильных клиентов.
REST больше не справлялся: каждое обновление приложения требовало всё больше запросов к серверу, а мобильный интернет не прощал лишних килобайт.
Команда Facebook решила, что сервер не должен диктовать, какие данные возвращать.
Вместо этого клиент должен описывать свои потребности декларативно — “мне нужны вот такие данные, вот в такой структуре”.
В 2015 году Facebook открыл исходный код GraphQL, и он быстро стал стандартом в индустрии.
Сегодня его используют GitHub, Shopify, Twitter, Netflix, Pinterest, Airbnb и тысячи других компаний.
3. Основная идея GraphQL
Главная концепция GraphQL проста, но революционна:
клиент сам определяет, какие данные ему нужны.
Клиент не делает серию запросов к разным ресурсам, как в REST.
Он отправляет один запрос на сервер с точным описанием нужных полей, а сервер возвращает данные в том же формате.
Пример запроса:
query {
user(id: 42) {
name
avatar
posts(limit: 3) {
title
likes
}
}
}Ответ сервера:
{
"data": {
"user": {
"name": "Den",
"avatar": "https://example.com/den.jpg",
"posts": [
{ "title": "gRPC и Java", "likes": 120 },
{ "title": "GraphQL под капотом", "likes": 80 },
{ "title": "Spring Boot и микросервисы", "likes": 95 }
]
}
}
}Клиент получает ровно то, что запросил — ни байта больше, ни меньше.
Больше нет проблемы overfetching или underfetching.
#Java #middle #GraphQL
👍2
4. Как это работает
В GraphQL всё держится на схеме (schema).
Она описывает, какие типы данных доступны, какие поля у них есть и какие операции разрешены.
Пример схемы:
GraphQL строго типизирован.
Клиент знает, какие поля доступны и какого они типа, а сервер может валидировать запрос до его выполнения.
5. Ключевые преимущества GraphQL
1. Гибкость запросов
Клиент формирует запрос под себя:
на мобильном — только name и avatar,
в вебе — name, posts, comments.
Сервер не меняется, меняется лишь запрос.
2. Один запрос — много данных
GraphQL позволяет собрать связанные сущности за один вызов.
В REST для этого нужно было несколько запросов, теперь достаточно одного.
3. Строгая типизация
Схема описана декларативно, и клиент может проверять запросы ещё до выполнения.
Ошибки, вроде “такого поля нет” или “тип не совпадает”, ловятся на этапе компиляции.
4. Эволюция без версий
GraphQL не требует /v1, /v2, /v3.
Добавил поле — клиенты, которые его не запрашивают, даже не заметят изменений.
Старые клиенты продолжают работать, новые используют расширенные возможности.
5. Самодокументируемость
GraphQL-сервер знает всю структуру данных.
Это позволяет автоматически генерировать документацию и визуальные IDE вроде GraphiQL или Apollo Sandbox, где можно исследовать схему и писать запросы интерактивно.
6. Почему GraphQL особенно популярен во фронтенде
Фронтенд-разработка — динамичная среда:
разные страницы требуют разные наборы данных, часто меняются требования, нужны быстрые итерации.
GraphQL идеально вписывается в этот процесс, потому что:
Разработчик фронтенда сам решает, какие поля ему нужны.
Не нужно ждать, пока backend добавит новый эндпоинт.
Данные приходят в предсказуемом виде, строго по типам.
Поддерживаются инструменты вроде Apollo Client или Relay, которые кэшируют и синхронизируют данные автоматически.
Именно поэтому GraphQL сегодня стал де-факто стандартом для фронтенд-команд крупных проектов.
REST чаще используется для внешних публичных API, gRPC — для связи микросервисов,
а GraphQL стал интерфейсом между фронтом и внутренним миром данных.
#Java #middle #GraphQL
В GraphQL всё держится на схеме (schema).
Она описывает, какие типы данных доступны, какие поля у них есть и какие операции разрешены.
Пример схемы:
type User {
id: ID!
name: String!
avatar: String
posts(limit: Int): [Post]
}
type Post {
id: ID!
title: String!
likes: Int!
}
type Query {
user(id: ID!): User
}
type — описание структуры данных, аналог класса в Java.
Query — “входная точка”, через которую клиент получает данные.
! — обязательное поле.
[Post] — список постов.GraphQL строго типизирован.
Клиент знает, какие поля доступны и какого они типа, а сервер может валидировать запрос до его выполнения.
5. Ключевые преимущества GraphQL
1. Гибкость запросов
Клиент формирует запрос под себя:
на мобильном — только name и avatar,
в вебе — name, posts, comments.
Сервер не меняется, меняется лишь запрос.
2. Один запрос — много данных
GraphQL позволяет собрать связанные сущности за один вызов.
В REST для этого нужно было несколько запросов, теперь достаточно одного.
3. Строгая типизация
Схема описана декларативно, и клиент может проверять запросы ещё до выполнения.
Ошибки, вроде “такого поля нет” или “тип не совпадает”, ловятся на этапе компиляции.
4. Эволюция без версий
GraphQL не требует /v1, /v2, /v3.
Добавил поле — клиенты, которые его не запрашивают, даже не заметят изменений.
Старые клиенты продолжают работать, новые используют расширенные возможности.
5. Самодокументируемость
GraphQL-сервер знает всю структуру данных.
Это позволяет автоматически генерировать документацию и визуальные IDE вроде GraphiQL или Apollo Sandbox, где можно исследовать схему и писать запросы интерактивно.
6. Почему GraphQL особенно популярен во фронтенде
Фронтенд-разработка — динамичная среда:
разные страницы требуют разные наборы данных, часто меняются требования, нужны быстрые итерации.
GraphQL идеально вписывается в этот процесс, потому что:
Разработчик фронтенда сам решает, какие поля ему нужны.
Не нужно ждать, пока backend добавит новый эндпоинт.
Данные приходят в предсказуемом виде, строго по типам.
Поддерживаются инструменты вроде Apollo Client или Relay, которые кэшируют и синхронизируют данные автоматически.
Именно поэтому GraphQL сегодня стал де-факто стандартом для фронтенд-команд крупных проектов.
REST чаще используется для внешних публичных API, gRPC — для связи микросервисов,
а GraphQL стал интерфейсом между фронтом и внутренним миром данных.
#Java #middle #GraphQL
👍2
Что выведет код?
#Tasks
import java.util.HashMap;
import java.util.Map;
public class Task111125 {
public static void main(String[] args) {
Map<String, Integer> map = new HashMap<>();
map.put("a", 1);
map.put("b", 2);
map.put("c", null);
map.merge("a", 10, (oldVal, newVal) -> null);
map.merge("b", 20, (oldVal, newVal) -> oldVal + newVal);
map.merge("c", 30, (oldVal, newVal) -> oldVal + newVal);
map.merge("d", 40, (oldVal, newVal) -> oldVal + newVal);
System.out.println(map.get("a"));
System.out.println(map.get("b"));
System.out.println(map.get("c"));
System.out.println(map.get("d"));
}
}
#Tasks
🔥1
Варианты ответа:
Anonymous Quiz
0%
1 22 30 40
44%
null 22 null 40
44%
null 22 30 40
11%
1 22 null 40
Вопрос с собеседований
Что такое ApplicationContext в Spring?🤓
Ответ:
ApplicationContext — это контейнер, управляющий созданием и связью бинов.
Он сканирует классы, применяет зависимости, обрабатывает аннотации и управляет жизненным циклом.
Это сердце Spring, реализующее IoC и DI.
#собеседование
Что такое ApplicationContext в Spring?
Ответ:
Он сканирует классы, применяет зависимости, обрабатывает аннотации и управляет жизненным циклом.
Это сердце Spring, реализующее IoC и DI.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
История IT-технологий сегодня — 12 ноября
ℹ️ Кто родился в этот день
Дэвид Итан Каллер (родился 12 ноября 1959 г.) — американский учёный в области компьютерных систем; один из авторов TinyOS и руководителей работ по беспроводным сенсорным сетям (Berkeley Motes), PlanetLab и масштабируемым параллельным системам.
🌐 Знаковые события
1965 — в СССР запускается в сторону Венеры автоматическая межпланетная станция «Венера-2».
1980 — американская автоматическая межпланетная станция «Вояджер-1», отправленная 5 сентября 1977, пересекает орбиту Сатурна, проходя от него на расстоянии 124 000 км и в 4500 км от его спутника Титана.
#Biography #Birth_Date #Events #12Ноября
Дэвид Итан Каллер (родился 12 ноября 1959 г.) — американский учёный в области компьютерных систем; один из авторов TinyOS и руководителей работ по беспроводным сенсорным сетям (Berkeley Motes), PlanetLab и масштабируемым параллельным системам.
1965 — в СССР запускается в сторону Венеры автоматическая межпланетная станция «Венера-2».
1980 — американская автоматическая межпланетная станция «Вояджер-1», отправленная 5 сентября 1977, пересекает орбиту Сатурна, проходя от него на расстоянии 124 000 км и в 4500 км от его спутника Титана.
#Biography #Birth_Date #Events #12Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Раздел 6. Коллекции в Java
Глава 5. Map — отображения (словари)
Основные методы: containsKey - глубокое погружение в механизм проверки существования ключей
Основная концепция метода containsKey заключается в предоставлении быстрого и эффективного способа проверки принадлежности ключа к домену Map. В отличие от метода get, который возвращает ассоциированное значение, containsKey фокусируется исключительно на факте существования связи, что делает его особенно полезным в сценариях предварительной проверки перед выполнением дорогостоящих операций или в логике условного выполнения.
Общий алгоритм работы containsKey
Процесс выполнения метода containsKey(key) представляет собой последовательность взаимосвязанных этапов, каждый из которых вносит свой вклад в общую эффективность и корректность операции:
Фаза предварительной обработки и валидации:
Анализ типа и состояния ключа на соответствие требованиям конкретной реализации Map
Проверка специальных случаев, таких как null-ключи, с учетом специфики реализации
Подготовка ключа к процессу поиска через вычисление производных характеристик
Фаза навигации и локализации:
Определение целевой области внутри структуры данных, где потенциально может находиться искомый ключ
Применение специализированных алгоритмов навигации, адаптированных под внутреннюю организацию Map
Постепенное сужение области поиска через последовательные проверки и сравнения
Фаза точного сравнения и верификации:
Выполнение точной проверки соответствия через механизмы сравнения, специфичные для реализации
Учет семантики равенства, которая может варьироваться от ссылочного до глубокого сравнения
Формирование итогового результата на основе всех проведенных проверок
Детальный разбор для HashMap
Процесс хэширования и определения бакета
В HashMap проверка существования начинается с вычисления хэш-кода ключа, однако система использует не просто результат метода hashCode(), а применяет дополнительную трансформацию для улучшения распределения. Этот процесс, известный как "вторичное хэширование" или "perturbation", включает битовые операции для смешивания старших и младших битов хэш-кода, что значительно уменьшает вероятность коллизий для ключей с плохими хэш-функциями.
После вычисления оптимизированного хэша определяется индекс бакета через побитовую операцию AND между хэш-значением и размером массива минус один. Эта операция эффективна благодаря гарантии того, что размер массива в HashMap всегда является степенью двойки, что обеспечивает равномерное покрытие всех возможных индексов и минимизирует количество пустых проверок.
#Java #для_новичков #beginner #Map #containsKey
Глава 5. Map — отображения (словари)
Основные методы: containsKey - глубокое погружение в механизм проверки существования ключей
Основная концепция метода containsKey заключается в предоставлении быстрого и эффективного способа проверки принадлежности ключа к домену Map. В отличие от метода get, который возвращает ассоциированное значение, containsKey фокусируется исключительно на факте существования связи, что делает его особенно полезным в сценариях предварительной проверки перед выполнением дорогостоящих операций или в логике условного выполнения.
Общий алгоритм работы containsKey
Процесс выполнения метода containsKey(key) представляет собой последовательность взаимосвязанных этапов, каждый из которых вносит свой вклад в общую эффективность и корректность операции:
Фаза предварительной обработки и валидации:
Анализ типа и состояния ключа на соответствие требованиям конкретной реализации Map
Проверка специальных случаев, таких как null-ключи, с учетом специфики реализации
Подготовка ключа к процессу поиска через вычисление производных характеристик
Фаза навигации и локализации:
Определение целевой области внутри структуры данных, где потенциально может находиться искомый ключ
Применение специализированных алгоритмов навигации, адаптированных под внутреннюю организацию Map
Постепенное сужение области поиска через последовательные проверки и сравнения
Фаза точного сравнения и верификации:
Выполнение точной проверки соответствия через механизмы сравнения, специфичные для реализации
Учет семантики равенства, которая может варьироваться от ссылочного до глубокого сравнения
Формирование итогового результата на основе всех проведенных проверок
Детальный разбор для HashMap
Процесс хэширования и определения бакета
В HashMap проверка существования начинается с вычисления хэш-кода ключа, однако система использует не просто результат метода hashCode(), а применяет дополнительную трансформацию для улучшения распределения. Этот процесс, известный как "вторичное хэширование" или "perturbation", включает битовые операции для смешивания старших и младших битов хэш-кода, что значительно уменьшает вероятность коллизий для ключей с плохими хэш-функциями.
После вычисления оптимизированного хэша определяется индекс бакета через побитовую операцию AND между хэш-значением и размером массива минус один. Эта операция эффективна благодаря гарантии того, что размер массива в HashMap всегда является степенью двойки, что обеспечивает равномерное покрытие всех возможных индексов и минимизирует количество пустых проверок.
#Java #для_новичков #beginner #Map #containsKey