АзимутJava

Вопрос 4. Proxy паттерн. #java #pattern Proxy. Прокси выполняет роль агента который находится на полпути к целевому объекту и принимает запросы от клиента. Целевой объект получает и исполняет запросы уже от прокси. Поэтому целевой объект может фокусироваться только на своих задачах, а дополнительный функционал делегирует прокси. Пример из жизни Вы - Агент по недвижимости - Хозяин квартиры. Цели прокси: 1. Контроль доступа к целевым объектам 2. Наделение целевого объекта дополнительным функционалом Proxy создаются через прокси-паттерн, с использованием общего с цлевым объектом интерфейса. Чтобы создать прокси нужны три шага: 1. Имплементируем прокси от того же интерфейса что и целевой класс. 2. Через конструктор прокси-класса сохраняем целевой класс 3. В методах прокси-класса - выполняем доп логику и вызываем метод целевого класса или наоборот. Преимущества прокси: 1. Open-closed принцип - целевой класс открыт для расширения, но закрыт для изменений 2. Single responsibility - каждый класс отвечает за свои задачи Недостатки: 1. возрастает сложность кода 2. дублирование кода - требуется имплементировать интерфейс целиком. Последнее решается JDK dynamic proxy, но об этом позднее.

Бины можно создавать в обычных компонентах, не конфигурационных классах. Такая семантика бинов (без @Configuration) называется lite-bean и в целом ведет себя также как обычный бин, за тем исключением что внутри lite-бина другие бин-методы вызываются как обычные методы, без прокси CGLIB, по аналогии с @Transactional. Обычные бины при обращении к другим бин-методам - берут значение из контекста. lite-бины, обращаясь ко внутренним бин-методам - будут дергать их напрямую. Цена за lite. После создания бина - значение уже будет возвращаться из контекста. Учитывайте разность поведения lite и обычных бинов в своем приложении.

Почему при созданнии @Bean не в конфигурационном классе, а в компоненте - легче словить цикличную зависимость. Бины можно создавать в обычных компонентах, не конфигурационных классах. Такая семантика бинов (без @Configuration) называется lite-bean - но об этом позднее. Группирование бинов в классах @Configuration декомпозирует логику формирования bean-методов и классов-component-ов. Декомпозиция уменьшит вероятность того что вы будете вынуждены рефакторить сервисы, репозитории и прочие - из-за того что разложили бины в классы-компоненты. И да, @Configuration - тоже @Component, но это только означает что класс автоматически попадает в список кандидатов на попадание в контекст Spring. Ниже простой пример цикличной зависимости в с использованием lite-бинов. В данном коде бины из одного класса - требуются для конструктора другого. Проблема легко решается вынесением бинов в класс @Configuration

PECS - продюсер - лучше <T extends>, консюмер - <T super>.

Try + catch|finnaly! Просто try использовать нельзя. Исключение - try с ресурсами. Требуется проверка.