🕯 Паттерн Factory (Фабрика)

Factory — это порождающий паттерн, который предоставляет интерфейс для создания объектов в суперклассе, но позволяет подклассам изменять тип создаваемых объектов.

Использование:

🔹 Когда заранее неизвестны конкретные классы объектов, с которыми придётся работать.
🔹 Когда нужно централизовать логику создания объектов, чтобы избежать дублирования кода.
🔹 Когда система должна быть независимой от процесса создания, композиции и представления объектов.

Преимущества:

1️⃣ Снижает связанность кода с конкретными классами, делая систему более гибкой.
2️⃣ Улучшает структуру кода за счёт выделения логики создания объектов в отдельные классы.
3️⃣ Упрощает добавление новых типов объектов, не изменяя существующий код.

Недостатки:

1️⃣ Увеличивает количество классов в проекте, что усложняет его поддержку.
2️⃣ Требует понимания принципов абстракции и иерархий, что может усложнить первоначальное восприятие.

📌 Factory широко применяется для создания объектов в системах, где тип создаваемого объекта зависит от условий, например, в логике обработки различных пользовательских запросов или для генерации разных типов документов.

ℹ️ Что такое @Transactional в Spring?

@Transactional — это аннотация, которая управляет транзакциями в Spring. Она позволяет автоматически начать, зафиксировать или откатить транзакцию при выполнении бизнес-логики. Применяется к методам или классам, где важно обеспечить целостность данных.

🔹 Как работает:

Когда метод помечен @Transactional, Spring создает прокси-объект, который начинает транзакцию до выполнения метода и завершает её после. В случае исключения транзакция откатывается, если оно не является проверяемым (checked exception).

🔹 Конфигурации @Transactional:

▪️ Propagation (распространение):

- REQUIRED (по умолчанию): метод должен выполняться в существующей транзакции, если она есть, иначе создается новая.
- REQUIRES_NEW: всегда создает новую транзакцию, приостанавливая текущую.
- SUPPORTS: метод может выполняться в транзакции, но не требует её обязательного наличия.
- MANDATORY: требует существования транзакции, иначе будет выброшено исключение.
- NOT_SUPPORTED: метод выполняется без транзакции, даже если она существует.
- NEVER: запрещает выполнение метода в транзакции, иначе выбрасывается исключение.
- NESTED: позволяет создавать вложенные транзакции, которые могут быть откатаны отдельно от внешней.

▪️ Isolation (изолированность):

- DEFAULT: уровень изоляции БД по умолчанию.
- READ_UNCOMMITTED: минимальная изоляция, позволяет читать незавершенные изменения.
- READ_COMMITTED: запрещает чтение незавершенных транзакций.
- REPEATABLE_READ: гарантирует, что данные не изменятся во время транзакции.
- SERIALIZABLE: максимальная изоляция, исключает фантомные записи.

▪️ Timeout и Rollback:

timeout: ограничивает время выполнения транзакции (по умолчанию бесконечно).
rollbackFor/noRollbackFor: настраивают, какие исключения должны вызвать откат или нет.

🔹 Когда @Transactional не сработает?

- @Transactional не срабатывает, если метод с этой аннотацией вызывается внутри другого метода того же класса. Это связано с тем, что Spring использует прокси для управления транзакциями, и он активируется только при внешних вызовах. Когда метод вызывается из другого метода того же класса, прокси не задействуется, и транзакция не будет создана.
- Также нужно помнить, что аннотация не работает с private методами.

💥 Волшебные методы в Spring Data JPA: скрытые возможности работы с данными

В Spring Data JPA можно создавать "волшебные" методы в репозиториях, которые автоматически генерируют SQL-запросы на основе имени метода. Это очень мощный инструмент, который ускоряет разработку и упрощает работу с базой данных. Вместо написания SQL-запросов вручную, достаточно правильно написать название метода, и фреймворк создаст нужный SQL запрос.

🔵 Примеры возможностей:

1️⃣ Поиск по полю:

Метод:

findByEmail(String email)

Генерируемый запрос:

SELECT * FROM users WHERE email = ?;

2️⃣ Комбинирование условий (с помощью AND и OR):

Метод:

findByFirstNameAndLastName(String firstName, String lastName)

Генерируемый запрос:

SELECT * FROM users WHERE first_name = ? AND last_name = ?;

Метод:

findByAgeOrSalary(int age, int salary)

Генерируемый запрос:

SELECT * FROM users WHERE age = ? OR salary = ?;

3️⃣ Диапазоны значений:

Метод:

findByAgeBetween(int startAge, int endAge)

Генерируемый запрос:

SELECT * FROM users WHERE age BETWEEN ? AND ?;

4️⃣ Сравнение значений:

Метод:

findBySalaryGreaterThan(int salary)

Генерируемый запрос:

SELECT * FROM users WHERE salary > ?;

5️⃣Сортировка результатов:

Метод:

findByLastNameOrderByFirstNameAsc(String lastName)

Генерируемый запрос:

SELECT * FROM users WHERE last_name = ? ORDER BY first_name ASC;

6️⃣ Частичное совпадение:

Метод:

findByNameContaining(String keyword)

Генерируемый запрос:

SELECT * FROM users WHERE name LIKE '%?%';

7️⃣ Работа с NULL:

Метод:

findByMiddleNameIsNull()

Генерируемый запрос:

SELECT * FROM users WHERE middle_name IS NULL;

8️⃣ Ограничение количества записей:

Метод:

findTop3BySalaryGreaterThan(int salary)

Генерируемый запрос:

SELECT * FROM users WHERE salary > ? LIMIT 3;

9️⃣ Поиск по коллекции значений:

Метод:

findByRoleIn(List<String> roles)

Генерируемый запрос:

SELECT * FROM users WHERE role IN (?);

⚠️ Недостатки использования волшебных методов:

- Ограниченная гибкость: Когда запросы становятся сложными, волшебные методы перестают быть удобными. Например, сложно создать метод для многоступенчатых операций, объединений или работы с подзапросами.
- Трудности с оптимизацией: Автоматически сгенерированные SQL-запросы могут быть не такими оптимальными, как вручную написанные. Это может негативно влиять на производительность приложения, особенно при работе с большими объёмами данных.
- Неочевидность логики: В сложных проектах имя метода может становиться длинным и трудночитаемым. Это усложняет понимание логики запроса, что может запутать других разработчиков, работающих с кодом.
- Отсутствие контроля: Разработчик не всегда контролирует точную структуру генерируемого запроса, что может привести к неожиданным результатам, особенно если в базе данных есть индексы или другие особенности структуры.

🔼Полезные советы:

- Используйте волшебные методы для простых запросов и CRUD-операций.
- Для более сложных случаев лучше использовать @Query и писать запросы вручную.

🔍 Обработка исключений с помощью Try-With-Resources в Java

В Java 7 была представлена мощная конструкция Try-With-Resources, которая значительно упрощает управление ресурсами, такими как файлы, соединения с БД или сокеты. Это улучшение позволяет автоматически закрывать ресурсы, предотвращая утечки памяти. Любые объекты, реализующие интерфейс AutoCloseable, можно безопасно использовать в блоке try. Java сама вызовет метод close() в конце блока, даже если произошло исключение.

📌 Преимущества:

- Нет необходимости в блоках finally для ручного закрытия ресурсов.
- Можно использовать несколько ресурсов в одном блоке try.
- Исключает риск утечек, особенно при работе с внешними ресурсами.

try (BufferedReader reader = new BufferedReader(new FileReader("file.txt"))) {
    String line = reader.readLine();
    System.out.println(line);
} catch (IOException e) {
    e.printStackTrace();
}

Этот подход не только уменьшает количество шаблонного кода, но и делает обработку исключений более предсказуемой. Для более сложных систем, где важно управление ресурсами, Try-With-Resources становится незаменимым инструментом.

💡 Try-With-Resources может комбинироваться с собственными классами, реализующими AutoCloseable, чтобы управлять закрытием любых типов ресурсов.

Если хотите быть уверены в качестве кода — обратите внимание на 𝐒𝐨𝐧𝐚𝐫𝐐𝐮𝐛𝐞 👇

Этот инструмент автоматически анализирует код, находит ошибки и уязвимости, и помогает поддерживать чистоту проекта. Поддерживает более 25 языков и легко интегрируется в CI/CD. Все отчеты в одном месте, включая технический долг и проблемы безопасности.

🔗 Попробовать SonarQube

🕯 Паттерн Мост (Bridge)

Bridge — это структурный паттерн, который разделяет абстракцию и её реализацию, позволяя изменять их независимо друг от друга. Это достигается созданием интерфейса (абстракции) и его конкретных реализаций, которые можно менять, не влияя на абстракцию.

Использование:

🔹 Когда нужно разделить сложные системы на отдельные, независимые части.
🔹 Когда требуется поддерживать множество вариантов реализации для одной и той же абстракции.
🔹 Когда необходимо минимизировать связанность между абстракцией и её реализацией, делая систему более гибкой и расширяемой.

Преимущества:

1️⃣ Снижает связанность между абстракцией и реализацией, что упрощает модификации.
2️⃣ Позволяет изменять реализации без изменения кода абстракции.
3️⃣ Упрощает расширение системы за счёт добавления новых абстракций и реализаций.

Недостатки:

1️⃣ Увеличивает сложность проекта из-за необходимости введения дополнительных классов.
2️⃣ Могут возникнуть трудности с отладкой, если абстракция и реализация сильно изолированы.

📌 Мост особенно полезен в случаях, когда нужно поддерживать несколько платформ или драйверов для взаимодействия с разными устройствами.

ℹ️ Как устроен под капотом LinkedHashMap?

LinkedHashMap — это реализация интерфейса Map, которая сохраняет порядок добавления элементов. В отличие от обычного HashMap, где элементы могут быть расположены случайным образом, LinkedHashMap поддерживает последовательность вставки или порядок доступа. Это достигается благодаря использованию двусвязного списка, который связывает все элементы карты.

🔹 Структура LinkedHashMap

Основой LinkedHashMap является та же хэш-таблица, что и в HashMap, но с дополнительной структурой двусвязного списка для сохранения порядка элементов:

▪️ Каждая запись (entry) в LinkedHashMap содержит ссылки на предыдущий и следующий элементы. Это позволяет поддерживать порядок добавления или порядок последнего доступа.
▪️ Сначала выполняется хэширование ключей для быстрой вставки и поиска, как в HashMap, а уже потом запись связывается в список.

🔹 Производительность

▪️ Вставка: Добавление новых элементов выполняется за O(1), поскольку элементы добавляются в конец двусвязного списка, а хэш-таблица используется для поиска свободной позиции.
▪️ Удаление: Удаление элемента требует корректировки ссылок в двусвязном списке, что увеличивает накладные расходы, но также выполняется за O(1).
▪️ Поиск: Операция поиска по ключу происходит с использованием хэш-таблицы и выполняется за O(1), как и в HashMap.
▪️ Множественные коллизии: в худшем случае все операции будут выполняться с O(n), если допустить множественные коллизии.

🔹 Использование памяти

Каждая запись LinkedHashMap содержит дополнительные ссылки на предыдущий и следующий элементы, что увеличивает потребление памяти по сравнению с HashMap. Однако это оправдано, если важен порядок элементов.

🔹 Преимущества и недостатки

▪️ Преимущества:

- Сохранение порядка вставки: LinkedHashMap гарантирует, что элементы будут извлекаться в том порядке, в котором они были добавлены.
- Порядок доступа: Можно настроить LinkedHashMap на удаление самых старых элементов, что полезно для кэшей, где используется политика LRU (Least Recently Used).
- Предсказуемость итераций: В отличие от HashMap, где порядок элементов может изменяться, LinkedHashMap всегда сохраняет стабильный порядок.

▪️ Недостатки:

- Более высокое потребление памяти: Дополнительные ссылки на предыдущие и следующие элементы увеличивают память на каждую запись.
- Скорость: LinkedHashMap немного медленнее HashMap из-за поддержания порядка элементов.