Абстракция и полиморфизм
Одна из сильных сторон использования интерфейса List — принцип полиморфизма. В своем коде вы можете объявить переменную типа List, а затем присвоить ей любой объект, который реализует этот интерфейс.
Это позволяет писать гибкий и слабосвязанный код. Основная логика вашей программы, которая использует методы add, get, remove, будет работать с любой реализацией List. А вы, в зависимости от конкретных требований к производительности (например, если чаще нужен быстрый доступ по индексу или частое добавление в начало), можете легко подменить одну реализацию на другую, не переписывая весь код.
#Java #для_новичков #beginner #List
Одна из сильных сторон использования интерфейса List — принцип полиморфизма. В своем коде вы можете объявить переменную типа List, а затем присвоить ей любой объект, который реализует этот интерфейс.
List<String> myList; // Объявление переменной интерфейсного типа
myList = new ArrayList<>(); // Работаем с динамическим массивом
// ... позже в коде ...
myList = new LinkedList<>(); // Теперь работаем со связным списком
Это позволяет писать гибкий и слабосвязанный код. Основная логика вашей программы, которая использует методы add, get, remove, будет работать с любой реализацией List. А вы, в зависимости от конкретных требований к производительности (например, если чаще нужен быстрый доступ по индексу или частое добавление в начало), можете легко подменить одну реализацию на другую, не переписывая весь код.
#Java #для_новичков #beginner #List
👍2
Что выведет код?
#Tasks
public class Task201125 {
public static void main(String arg) {
System.out.println("Hello from single arg main");
}
public static void main(String[] args) {
System.out.println("Hello from main");
}
public static void main() {
System.out.println("Hello from parameterless main");
}
}#Tasks
👍1
Варианты ответа:
Anonymous Quiz
57%
Hello from main
14%
Hello from parameterless main
24%
Ошибка компиляции
5%
Исключение времени выполнения
👍2
Вопрос с собеседований
Что такое fail-fast и fail-safe итераторы?🤓
Ответ:
Fail-fast итераторы бросают ConcurrentModificationException при модификации коллекции.
Fail-safe работают со snapshot-копией, не влияющей на оригинал.
Первые быстрее, вторые безопаснее, но дороже по памяти. Выбор зависит от требований к производительности и стабильности.
#собеседование
Что такое fail-fast и fail-safe итераторы?
Ответ:
Fail-safe работают со snapshot-копией, не влияющей на оригинал.
Первые быстрее, вторые безопаснее, но дороже по памяти. Выбор зависит от требований к производительности и стабильности.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
История IT-технологий сегодня — 21 ноября
ℹ️ Кто родился в этот день
Никола́й Вале́рьевич Ду́ров (род. 21 ноября 1980, Ленинград) — российский программист и математик, участвовал в разработке Telegram; известен как один из ключевых технических авторов мессенджера.
🌐 Знаковые события
1998 — первый запуск китайской беспилотной космической ракеты.
#Biography #Birth_Date #Events #21Ноября
Никола́й Вале́рьевич Ду́ров (род. 21 ноября 1980, Ленинград) — российский программист и математик, участвовал в разработке Telegram; известен как один из ключевых технических авторов мессенджера.
1998 — первый запуск китайской беспилотной космической ракеты.
#Biography #Birth_Date #Events #21Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
Фрагменты, директивы и переменные
GraphQL — декларативный язык, но его мощь раскрывается по-настоящему, когда вы начинаете использовать фрагменты, директивы и переменные.
Эти инструменты позволяют:
избегать дублирования запросов,
включать или исключать поля динамически,
передавать аргументы безопасно,
строить сложные запросы, сохраняя читаемость.
1. Фрагменты
Фрагмент (fragment) — это именованный блок запроса, который описывает набор полей.
Он позволяет вынести общую часть и использовать её в нескольких местах.
Главная цель: избежать повторов полей.
Пример без фрагментов:
Версия с фрагментом
Как работает фрагмент
fragment UserBasic on User — объявление фрагмента.
User — тип, которому фрагмент принадлежит.
...UserBasic — вставка фрагмента.
Фрагменты можно вкладывать друг в друга и использовать с union и interface.
Кейсы, где фрагменты обязательны
Одинаковая структура данных в нескольких частях UI
Профили пользователей, карточки, списки.
Сложные запросы с глубокой вложенностью
Общие части выносятся в фрагменты.
Работа с interface и union
Позволяют описывать поля для нескольких типов.
Крупные запросы с десятками полей
Легче читать, тестировать и поддерживать.
2. Директивы
Директивы — это аннотации, которые модифицируют выполнение запроса.
Они влияют на структуру данных, которые вернёт сервер.
GraphQL имеет встроенные директивы и позволяет создавать свои.
2.1 Директива @include
Поле будет включено только если условие истинно.
2.2 Директива @skip
Обратная логика:
2.3 Директива @deprecated
Помечает поле устаревшим.
2.4 Кастомные директивы
Пример (схема):
Резолвер может модифицировать строку на лету (например, вернуть верхний регистр).
Это используется для логирования, авторизации, кеширования, маскирования данных.
3. Переменные в запросах
Переменные — это место, где GraphQL становится особенно полезным.
Они позволяют использовать один и тот же запрос с разными параметрами, не переписывая запрос.
3.1 Базовый пример
Запрос:
Переменные:
Сервер соединяет тело запроса и переменные и выполняет.
3.2 Переменные для input-объектов (в мутациях)
Мутация:
Переменные:
Это безопаснее, чем писать input прямо в теле мутации.
3.3 Комбинирование переменных с директивами
Комбинация:
один запрос,
два режима вывода данных,
ноль дублирования.
#Java #middle #GraphQL #Query
GraphQL — декларативный язык, но его мощь раскрывается по-настоящему, когда вы начинаете использовать фрагменты, директивы и переменные.
Эти инструменты позволяют:
избегать дублирования запросов,
включать или исключать поля динамически,
передавать аргументы безопасно,
строить сложные запросы, сохраняя читаемость.
1. Фрагменты
Фрагмент (fragment) — это именованный блок запроса, который описывает набор полей.
Он позволяет вынести общую часть и использовать её в нескольких местах.
Главная цель: избежать повторов полей.
Пример без фрагментов:
query {
user(id: 1) {
id
name
avatar
}
post(id: 10) {
author {
id
name
avatar
}
}
}
Повторяются три поля id, name, avatar.Версия с фрагментом
fragment UserBasic on User {
id
name
avatar
}
query {
user(id: 1) {
...UserBasic
}
post(id: 10) {
author {
...UserBasic
}
}
}
Теперь изменения структуры (например, добавление role) делаются в одном месте — фрагменте.Как работает фрагмент
fragment UserBasic on User — объявление фрагмента.
User — тип, которому фрагмент принадлежит.
...UserBasic — вставка фрагмента.
Фрагменты можно вкладывать друг в друга и использовать с union и interface.
Кейсы, где фрагменты обязательны
Одинаковая структура данных в нескольких частях UI
Профили пользователей, карточки, списки.
Сложные запросы с глубокой вложенностью
Общие части выносятся в фрагменты.
Работа с interface и union
Позволяют описывать поля для нескольких типов.
Крупные запросы с десятками полей
Легче читать, тестировать и поддерживать.
2. Директивы
Директивы — это аннотации, которые модифицируют выполнение запроса.
Они влияют на структуру данных, которые вернёт сервер.
GraphQL имеет встроенные директивы и позволяет создавать свои.
2.1 Директива @include
Поле будет включено только если условие истинно.
query GetUser($showAvatar: Boolean!) {
user(id: 1) {
name
avatar @include(if: $showAvatar)
}
}
Переменные:
{ "showAvatar": true }
Если showAvatar = false, поле avatar пропадёт из ответа целиком.2.2 Директива @skip
Обратная логика:
avatar @skip(if: $binaryMode)
Если binaryMode = true, поле будет пропущено.
2.3 Директива @deprecated
Помечает поле устаревшим.
type User {
username: String @deprecated(reason: "Use 'name' instead")
}
Эта директива влияет на документацию и IDE, но не на данные.2.4 Кастомные директивы
Пример (схема):
directive @upper on FIELD_DEFINITION
Резолвер может модифицировать строку на лету (например, вернуть верхний регистр).
Это используется для логирования, авторизации, кеширования, маскирования данных.
3. Переменные в запросах
Переменные — это место, где GraphQL становится особенно полезным.
Они позволяют использовать один и тот же запрос с разными параметрами, не переписывая запрос.
3.1 Базовый пример
Запрос:
query GetPost($id: ID!) {
post(id: $id) {
title
content
}
}Переменные:
{
"id": 100
}Сервер соединяет тело запроса и переменные и выполняет.
3.2 Переменные для input-объектов (в мутациях)
Мутация:
mutation CreatePost($input: CreatePostInput!) {
createPost(input: $input) {
id
title
}
}Переменные:
{
"input": {
"title": "GraphQL",
"content": "Powerful queries"
}
}Это безопаснее, чем писать input прямо в теле мутации.
3.3 Комбинирование переменных с директивами
query User(
$id: ID!,
$withPosts: Boolean!
) {
user(id: $id) {
name
posts @include(if: $withPosts) {
title
}
}
}
Комбинация:
один запрос,
два режима вывода данных,
ноль дублирования.
#Java #middle #GraphQL #Query
👍2
4. Реальные производственные кейсы
Кейc 1: мобильная и web-версия используют разные наборы полей
Мобильный клиент получает минимум данных.
Web — максимум.
Кейc 2: переиспользование структуры пользователя
Все блоки страницы используют одну структуру.
CRM-интерфейсы любят такое.
Кейc 3: миграции схемы через директивы
Старая модель:
Frontend получает предупреждение в IDE — никаких тайных поломок.
Кейc 4: сложные фильтры в одном запросе
Переменные:
#Java #middle #GraphQL #Query
Кейc 1: мобильная и web-версия используют разные наборы полей
query User(
$id: ID!,
$isMobile: Boolean!
) {
user(id: $id) {
name
avatar @skip(if: $isMobile)
posts @include(if: $isMobile) {
title
}
}
}
Мобильный клиент получает минимум данных.
Web — максимум.
Кейc 2: переиспользование структуры пользователя
fragment UserCard on User {
id
name
avatar
}
query PageData {
recommendedUsers { ...UserCard }
recentVisitors { ...UserCard }
followers { ...UserCard }
}Все блоки страницы используют одну структуру.
CRM-интерфейсы любят такое.
Кейc 3: миграции схемы через директивы
Старая модель:
username @deprecated(reason: "Use 'login' instead")
Frontend получает предупреждение в IDE — никаких тайных поломок.
Кейc 4: сложные фильтры в одном запросе
query FilterPosts($filter: PostFilter!) {
posts(filter: $filter) {
id
title
}
}Переменные:
{
"filter": {
"authorId": 1,
"tags": ["graphql", "java"],
"minLikes": 10
}
}#Java #middle #GraphQL #Query
👍2
Что выведет код?
#Tasks
public class Task211125 {
public static void main(String[] args) {
String s1 = "hello";
String s2 = "he" + "llo";
String s3 = "he";
String s4 = "llo";
String s5 = s3 + s4;
System.out.println(s1 == s2);
System.out.println(s1 == s5);
System.out.println(s1.equals(s5));
final String s6 = "he";
final String s7 = "llo";
String s8 = s6 + s7;
System.out.println(s1 == s8);
}
}#Tasks
👍1
Варианты ответа:
Anonymous Quiz
15%
true false true false
25%
true false true true
40%
true true true true
20%
false true true true
😱1
Вопрос с собеседований
Для чего используется CompletableFuture.anyOf()🤓
Ответ:
anyOf() запускает несколько асинхронных задач и завершается, как только выполнится любая.
Полезно, когда важен первый успешный результат.
Метод упрощает конкурентную работу, но требует аккуратного управления исключениями и понимания поведения оставшихся задач.
#собеседование
Для чего используется CompletableFuture.anyOf()
Ответ:
Полезно, когда важен первый успешный результат.
Метод упрощает конкурентную работу, но требует аккуратного управления исключениями и понимания поведения оставшихся задач.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
История IT-технологий сегодня — 22 ноября
ℹ️ Кто родился в этот день
Джеффри Дэвид Ульман (родился 22 ноября 1942 года) — американский теоретик информатики; автор классических учебников по компиляторам, теории вычислимости и базам данных, лауреат крупных наград в CS.
Википедия
Расмус Лердорф (дат. Rasmus Lerdorf; р. 22 ноября 1968) — датский программист, ныне живущий в Канаде, написавший в 1994 году набор скриптов на C, обрабатывающих шаблоны HTML-документов, позже воплотившийся в интерпретатор языка сценариев PHP, с помощью которого можно было решать различные задачи веб-приложений, включая не шаблонное создание сайтов для различных целей и направлений.
🌐 Знаковые события
1911 — лётчик Д. М. Сокольцов осуществил радиопередачу с самолёта на землю.
#Biography #Birth_Date #Events #22Ноября
Джеффри Дэвид Ульман (родился 22 ноября 1942 года) — американский теоретик информатики; автор классических учебников по компиляторам, теории вычислимости и базам данных, лауреат крупных наград в CS.
Википедия
Расмус Лердорф (дат. Rasmus Lerdorf; р. 22 ноября 1968) — датский программист, ныне живущий в Канаде, написавший в 1994 году набор скриптов на C, обрабатывающих шаблоны HTML-документов, позже воплотившийся в интерпретатор языка сценариев PHP, с помощью которого можно было решать различные задачи веб-приложений, включая не шаблонное создание сайтов для различных целей и направлений.
1911 — лётчик Д. М. Сокольцов осуществил радиопередачу с самолёта на землю.
#Biography #Birth_Date #Events #22Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
С 15.11 по 21.11
Предыдущий пост(с 08.11 по 14.11)
Воскресный мотивационный пост:
Не было мотивации
Запись встреч/видео:
JOOQ. Взаимодействуй с БД по-новому.
Обучающие статьи:
Java:
Коллекции в Java
Глава 2. List — списки в Java
Интерфейс List и его особенности
Глава 5. Map — отображения (словари)
Практика: В «Библиотеке» создать Map<String, Book> для быстрого поиска книги по названию.
GraphQL
Определение схемы в GraphQL (SDL)
Запросы и мутации в GraphQL
Фрагменты, директивы и переменные
Полезные статьи и видео:
Как написать приложение на JavaFX: гид для начинающих
MapStruct: как безобидный метод портит весь маппинг
Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование
Предыдущий пост(с 08.11 по 14.11)
Воскресный мотивационный пост:
Не было мотивации
Запись встреч/видео:
JOOQ. Взаимодействуй с БД по-новому.
Обучающие статьи:
Java:
Коллекции в Java
Глава 2. List — списки в Java
Интерфейс List и его особенности
Глава 5. Map — отображения (словари)
Практика: В «Библиотеке» создать Map<String, Book> для быстрого поиска книги по названию.
GraphQL
Определение схемы в GraphQL (SDL)
Запросы и мутации в GraphQL
Фрагменты, директивы и переменные
Полезные статьи и видео:
Как написать приложение на JavaFX: гид для начинающих
MapStruct: как безобидный метод портит весь маппинг
Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование
👍3
История IT-технологий сегодня — 23 ноября
ℹ️ Кто родился в этот день
Абхай Бхушан ( произношение на хинди: [əbʰəj bʰuːʂəɳː] ; родился 23 ноября 1944 г.) — индийский компьютерный учёный; автор оригинальной спецификации FTP и ряда ранних RFC для ARPANET/Интернета.
Магнус Даниэль Стенберг (23 ноября 1970) — шведский разработчик; создатель и ведущий разработчик проекта cURL, инструмента для работы с сетевыми протоколами, широко используемого в инфраструктуре.
🌐 Знаковые события
1924 — состоялась первая широковещательная передача Московского радио. Начало регулярного радиовещания в СССР.
Комментарий: Всего 100 лет назад... Только появилось радио, а теперь роботы, космос и интернет... Что будет еще через 100 лет?
#Biography #Birth_Date #Events #23Ноября
Абхай Бхушан ( произношение на хинди: [əbʰəj bʰuːʂəɳː] ; родился 23 ноября 1944 г.) — индийский компьютерный учёный; автор оригинальной спецификации FTP и ряда ранних RFC для ARPANET/Интернета.
Магнус Даниэль Стенберг (23 ноября 1970) — шведский разработчик; создатель и ведущий разработчик проекта cURL, инструмента для работы с сетевыми протоколами, широко используемого в инфраструктуре.
1924 — состоялась первая широковещательная передача Московского радио. Начало регулярного радиовещания в СССР.
Комментарий: Всего 100 лет назад... Только появилось радио, а теперь роботы, космос и интернет... Что будет еще через 100 лет?
#Biography #Birth_Date #Events #23Ноября
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Кем ты видишь себя в будущем в IT?
Сегодня в IT идёт каждый второй.
Кто-то по моде.
Кто-то за деньгами.
Но вот о чём почти никто не думает:
Кем ты хочешь стать через 5–10 лет?
И хочешь ли ты этого вообще?
Давайте об этом сегодня и поразмышляем.
Разработчик - это фундамент
Как бы банально ни звучало: разработчик - это основа IT.
Если убрать программистов, то рухнет всё: сервисы, приложения, бэкенды, интерфейсы - всё.
Но спустя годы работы некоторым становится тесно.
Кто-то устает просто решать таски.
Кому-то хочется больше влияния, кому-то — меньше рутины, кому-то — новых вызовов.
Куда можно расти дальше
1. Individual Contributor (IC): разработчик
Джун → мидл → сеньор → ведущий.
Ты пишешь код, решаешь сложные задачи, драйвишь качество.
Глубина и ширина.
Это путь для тех, кто любит и хочет продолжать создавать что-то своими руками.
2. Архитектор / системный инженер
От решения отдельных модулей - к проектированию больших систем.
Минимум строчек кода, больше схем, интеграций, рисков, компромиссов.
Тут ты уже не пишешь программу.
Ты формируешь её скелет, основу, генерируешь понимание как все это будет работать в связке, давая свою компетенцию и гарантии.
3. Тимлид (People Manager)
Тут код - уже не главное.
Главное - люди, процессы, сроки, коммуникация.
Мотивировать.
Помогать расти.
Разруливать конфликты.
Закрывать найм.
Ты превращаешься из разработчика в того, кто рулит и организует процесс разработки.
4. Техлид / Tech Lead
Эта позиция позволяет сохранить контроль над кодом, при этом руководя его написанием.
Ты остаёшься технически сильным, но получаешь влияние на команду.
Твоя зона: архитектура, ревью, стандарты, координация технического направления.
Без HR-функций, но с высокой ответственностью за качество.
5. Продуктовый путь (PM, Product Engineer)
Переход, от как запрограммировать - к а зачем это вообще нужно?
Пользовательские кейсы, метрики, ценность, гипотезы.
Ты становишься человеком, который превращает код в продукт, а не в набор функций.
А надо ли тебе это?
Когда приходит возможность выбирать - этот вопрос основной.
С одной стороны:
спокойная работа разработчиком, задачи, PR-ы, ревью, новые фреймворки и старое доброе легаси.
С другой:
рост, новые роли, новые риски, новые деньги.
Не каждому хочется руководить людьми.
Не каждый хочет отвечать за архитектуру.
Не всем нужен стресс, планирование, ответственность.
Кому-то достаточно закрывать таски и вечером залипать в сериалы 😂
И это тоже нормально.
Выбор есть у каждого.
Но решать придётся самому — трезво взвесив, чего ты реально хочешь.
Если статья зашла — поделись с другом и позови его на канал.
А мне — плюсик к карме 🤝😎
😎
#motivation
Сегодня в IT идёт каждый второй.
Кто-то по моде.
Кто-то за деньгами.
Но вот о чём почти никто не думает:
Кем ты хочешь стать через 5–10 лет?
И хочешь ли ты этого вообще?
Давайте об этом сегодня и поразмышляем.
Разработчик - это фундамент
Как бы банально ни звучало: разработчик - это основа IT.
Если убрать программистов, то рухнет всё: сервисы, приложения, бэкенды, интерфейсы - всё.
Но спустя годы работы некоторым становится тесно.
Кто-то устает просто решать таски.
Кому-то хочется больше влияния, кому-то — меньше рутины, кому-то — новых вызовов.
Куда можно расти дальше
1. Individual Contributor (IC): разработчик
Джун → мидл → сеньор → ведущий.
Ты пишешь код, решаешь сложные задачи, драйвишь качество.
Глубина и ширина.
Это путь для тех, кто любит и хочет продолжать создавать что-то своими руками.
2. Архитектор / системный инженер
От решения отдельных модулей - к проектированию больших систем.
Минимум строчек кода, больше схем, интеграций, рисков, компромиссов.
Тут ты уже не пишешь программу.
Ты формируешь её скелет, основу, генерируешь понимание как все это будет работать в связке, давая свою компетенцию и гарантии.
3. Тимлид (People Manager)
Тут код - уже не главное.
Главное - люди, процессы, сроки, коммуникация.
Мотивировать.
Помогать расти.
Разруливать конфликты.
Закрывать найм.
Ты превращаешься из разработчика в того, кто рулит и организует процесс разработки.
4. Техлид / Tech Lead
Эта позиция позволяет сохранить контроль над кодом, при этом руководя его написанием.
Ты остаёшься технически сильным, но получаешь влияние на команду.
Твоя зона: архитектура, ревью, стандарты, координация технического направления.
Без HR-функций, но с высокой ответственностью за качество.
5. Продуктовый путь (PM, Product Engineer)
Переход, от как запрограммировать - к а зачем это вообще нужно?
Пользовательские кейсы, метрики, ценность, гипотезы.
Ты становишься человеком, который превращает код в продукт, а не в набор функций.
А надо ли тебе это?
Когда приходит возможность выбирать - этот вопрос основной.
С одной стороны:
спокойная работа разработчиком, задачи, PR-ы, ревью, новые фреймворки и старое доброе легаси.
С другой:
рост, новые роли, новые риски, новые деньги.
Не каждому хочется руководить людьми.
Не каждый хочет отвечать за архитектуру.
Не всем нужен стресс, планирование, ответственность.
Кому-то достаточно закрывать таски и вечером залипать в сериалы 😂
И это тоже нормально.
Выбор есть у каждого.
Но решать придётся самому — трезво взвесив, чего ты реально хочешь.
Если статья зашла — поделись с другом и позови его на канал.
А мне — плюсик к карме 🤝😎
#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5