🕯 Паттерн Цепочка обязанностей (Chain of Responsibility)

Chain of Responsibility — это поведенческий паттерн, который позволяет передавать запросы по цепочке обработчиков, пока один из них не обработает запрос. Каждый обработчик в цепочке решает, может ли он обработать запрос или передать его следующему по цепочке.

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

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

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

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

Недостатки:

1️⃣ Может быть сложнее отслеживать, кто в конечном итоге обработал запрос, особенно при длинных цепочках.
2️⃣ Не гарантирует, что запрос будет обработан, если ни один из обработчиков не способен это сделать.
3️⃣ Может усложнить структуру программы при использовании большого числа обработчиков.

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

💥 Волшебные методы в Spring Data JPA: как создаются под капотом.

В продолжение прошлого поста, рассмотрим как этот механизм работает под капотом. Spring Data JPA позволяет создавать методы в репозиториях, которые генерируют запросы на основе имени метода. Под капотом этот механизм строится на строгой интерпретации имени метода, динамическом создании запросов и использовании JPA Criteria API или JPQL.

Давайте разберём глубже, как это работает и что происходит, в момент вызова волшебного метода:

1️⃣ Парсинг имени метода: PartTree

Класс PartTree (пакет org.springframework.data.repository.query.parser) играет ключевую роль в анализе имени метода. Когда репозиторий загружается в контексте Spring, каждый метод проверяется на соответствие предопределённым шаблонам. Основной принцип парсинга — разбиение имени метода на логические части (поля сущности, операторы и ключевые слова).

Пример метода:

findByFirstNameAndLastName(String firstName, String lastName).

PartTree разбивает это имя на части: findBy (операция), FirstName (поле), And (оператор), LastName (второе поле).

В результате класс PartTree создаёт синтаксическое дерево условий, которые затем будут преобразованы в SQL.

2️⃣ Генерация SQL-запросов: QueryLookupStrategy

После того как имя метода распознано, Spring Data JPA использует стратегию поиска запроса через QueryLookupStrategy (пакет org.springframework.data.repository.query). Этот класс отвечает за выбор подходящей стратегии для преобразования метода в SQL-запрос, что делает работу с запросами гибкой и удобной. Стратегии могут быть следующими:

- CREATE: Автоматически создаются запросы на основе имени метода (например, findBy, countBy и т.д.).
- USE_DECLARED_QUERY: Использует явно объявленные запросы (например, через аннотации @Query).
- CREATE_IF_NOT_FOUND: Попытка использовать явный запрос, а если он не найден — создать запрос динамически.

Если метод соответствует заранее определённым правилам (например, начинается с findBy), Spring Data JPA создаст запрос автоматически. Методы динамического создания запросов используют API JpaQueryCreator, который формирует запросы на основе дерева условий, построенного с помощью PartTree. Это дерево представляет собой структуру, которая разбивает имя метода на логические части (поля, операторы и условия) и преобразует их в SQL-запрос.

3️⃣ Конструирование запроса через JPA Criteria API или JPQL

В зависимости от сложности запроса и доступных данных, Spring решает, использовать ли для запроса JPA Criteria API или JPQL. Более простые запросы генерируются с помощью JPQL, для более сложных выбирается Criteria API. Каждый метод в репозитории после парсинга передаётся в CriteriaBuilder, который строит запрос на основе условий.

Пример генерации запроса с использованием Criteria API:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<User> query = cb.createQuery(User.class);
Root<User> user = query.from(User.class);

Predicate firstNamePredicate = cb.equal(user.get("firstName"), firstName);
Predicate lastNamePredicate = cb.equal(user.get("lastName"), lastName);

query.where(cb.and(firstNamePredicate, lastNamePredicate));
List<User> result = entityManager.createQuery(query).getResultList();

Этот код создаёт SQL-запрос, эквивалентный:

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

▪️ Операторы и ключевые слова

Spring Data JPA поддерживает большое количество операторов, таких как And, Or, GreaterThan, LessThan, Between, Like и другие. Каждый оператор обрабатывается в классе QueryCreator, где он преобразуется в соответствующее условие JPA Criteria API или JPQL.

Пример обработки оператора Between:

if (part.getType() == Part.Type.BETWEEN) {
    predicates.add(cb.between(root.get(part.getProperty()), minValue, maxValue));
}

Это условие будет интерпретировано как:

SELECT * FROM users WHERE age BETWEEN ? AND ?

▪️ Работа с коллекциями

Для работы с коллекциями Spring Data JPA использует оператор IN. Например, метод findByRoleIn(List<String> roles) будет преобразован в запрос с IN оператором.

Пример кода:

Predicate inPredicate = cb.in(user.get("role")).value(roles);
query.where(inPredicate);

Этот запрос эквивалентен:

SELECT * FROM users WHERE role IN (?, ?, ...)

4️⃣ Передача запроса в EntityManager

Когда запрос полностью построен, он передаётся в EntityManager, который занимается выполнением SQL-запроса и возвратом результата.

🔗 Документация: JpaRepository, PartTree, QueryLookupStrategy, JpaQueryCreator, EntityManager, Criteria API

ℹ️ Как работает Pageable в Spring?

Pageable — это мощный инструмент в Spring Data для работы с большими объемами данных, который позволяет разделить результат на страницы. Это оптимизирует память и улучшает производительность.

Вместо загрузки всех записей, например через findAll(), мы можем запросить только определенное количество данных (порции/страницы) и продолжать загружать по мере необходимости. Интерфейс Pageable создает запрос с параметрами LIMIT и OFFSET, что позволяет базе данных возвращать только нужные записи, начиная с определенного места.

🔵 Пример использования:

▪️ Репозиторий:

public interface UserRepository extends JpaRepository<User, Long> {}

▪️Сервис:

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    public Page<User> getUsersByPage(int page, int size) {
        Pageable pageable = PageRequest.of(page, size, Sort.by("name").ascending());
        return userRepository.findAll(pageable);
    }
}

Здесь PageRequest.of(page, size, Sort) создает объект Pageable, который указывает, какую страницу и сколько записей нужно получить, а также сортирует результат по имени в порядке возрастания.

▪️ Контроллер:

@RestController
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping("/users")
    public Page<User> getUsers(
        @RequestParam(defaultValue = "0") int page,
        @RequestParam(defaultValue = "20") int size) {
        return userService.getUsersByPage(page, size);
    }
}

Этот эндпоинт позволяет запрашивать данные по страницам. Например, /users?page=1&size=20 вернет вторую страницу с 20 записями.

🔵 Преимущества использования Pageable:

- Экономия памяти: Мы загружаем только небольшие порции данных.
- Легкость навигации: Можно переключаться между страницами.

🔵 Недостатки использования Pageable:

- Дополнительный запрос для подсчета записей: Spring Data выполняет запрос для получения общего числа записей.
- Ограниченная гибкость: При сложных запросах с множеством фильтраций и джоинов Pageable может быть не таким гибким, как ручные запросы с LIMIT и OFFSET.

⚠️ Важно: Пагинация удобна для больших объемов данных, но если данные постоянно обновляются, возможны проблемы с консистентностью между страницами. Записи могут дублироваться или пропадать.

🎮 API архитектурные стили

🔗 REST – популярный подход для публичных API и веб-приложений, поддерживает JSON, XML, HTML и текст.
🔗 SOAP – использует структуру сообщений с оберткой на основе XML. Применяется в платежных системах и телеком-сервисах, но имеет высокий порог входа.
🔗 GraphQL – гибкая схема и система типов, позволяет использовать JSON и подходит для сложных систем и мобильных API.
🔗 gRPC – высокопроизводительный фреймворк RPC, работает через протоколы сериализации, используется для высоконагруженных систем.
🔗 WebSocket – поддерживает двустороннюю связь, подходит для чатов и других приложений реального времени.
🔗 Webhook – асинхронный подход, применим для CI/CD процессов и платежных шлюзов.

📊 Paging vs. Segmentation

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

🔹 Пагинация:

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

Преимущества:
- Устраняет внешнюю фрагментацию.
- Облегчает работу с виртуальной памятью и перемещением страниц.
- Управление памятью становится более простым и эффективным.

🔹 Сегментация:

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

Преимущества:
- Обеспечивает логическое разделение кода и данных.
- Упрощает защиту и обмен сегментами.
- Поддерживает управление растущими структурами данных.

ℹ️ Как работает SSO

SSO (Single Sign-On) или Единая система аутентификации — это схема аутентификации, которая позволяет пользователю войти в разные системы, используя одну учетную запись.

На фото выше показан принцип работы SSO.

Шаг 1: Пользователь заходит в Gmail или любой другой сервис электронной почты. Gmail обнаруживает, что пользователь не авторизован, и перенаправляет его на SSO сервер аутентификации, который также обнаруживает отсутствие входа. Пользователь попадает на страницу авторизации SSO и вводит свои учетные данные.

Шаги 2-3: SSO сервер проверяет данные пользователя, создает глобальную сессию и выдает токен.

Шаги 4-7: Gmail проверяет токен на SSO сервере. Система аутентификации регистрирует Gmail и возвращает статус «действительно». Gmail отправляет пользователю защищенный ресурс.

Шаг 8: Из Gmail пользователь переходит на другой сайт Google, например, YouTube.

Шаги 9-10: YouTube обнаруживает, что пользователь не авторизован, и запрашивает подтверждение. SSO сервер находит уже активную сессию пользователя и выдает токен.

Шаги 11-14: YouTube проверяет токен на SSO сервере. Система аутентификации регистрирует YouTube и возвращает статус «действительно». YouTube отправляет пользователю защищенный ресурс.

✔️ Процесс завершен, и пользователь получает доступ к своим данным.

🕯 Паттерн Хранитель (Memento)

Memento — это поведенческий паттерн, который позволяет сохранять и восстанавливать прошлые состояния объекта, не нарушая инкапсуляции. С помощью Memento можно вернуться к предыдущим состояниям объекта, сохранив его историю изменений.

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

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

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

1️⃣ Обеспечивает сохранение и восстановление состояния объекта без раскрытия его внутренней структуры.
2️⃣ Поддерживает отмену изменений и возможность вернуться к предыдущему состоянию, сохраняя историю.
3️⃣ Позволяет реализовать функциональность undo-redo, гибко восстанавливая состояния объектов.

Недостатки:

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

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