Обновлено и немного переделано оглавление! 👏
Добавлен план изучения 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
👍1
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
👍2