🟢 Junior Level

BeanPostProcessor (BPP) — это механизм Spring для изменения бинов после их создания.

Зачем: BPP нужен, когда вы хотите добавить поведение к бинам без изменения их кода. Например: создать прокси для транзакций (@Transactional), добавить логирование (@Aspect), обернуть в кэш (@Cacheable). Через BPP работают ВСЕ Spring-аннотации, добавляющие поведение.

Простая аналогия: Фабрика выпускает игрушки, а BPP — это отдел контроля, который может добавить наклейку, упаковку или вообще заменить игрушку.

@Component
public class MyBPP implements BeanPostProcessor {
    
    // ДО инициализации (@PostConstruct)
    public Object postProcessBeforeInitialization(Object bean, String name) {
        return bean;  // Можно изменить или заменить
    }
    
    // ПОСЛЕ инициализации
    public Object postProcessAfterInitialization(Object bean, String name) {
        return bean;  // Здесь создаются прокси!
    }
}

---

🟡 Middle Level

Что делает BPP

1. Конструктор бина
2. Внедрение зависимостей
3. BPP.postProcessBeforeInitialization()
4. @PostConstruct
5. BPP.postProcessAfterInitialization() ← Proxy создаётся здесь!
6. Бин готов

Создание прокси

@Override
public Object postProcessAfterInitialization(Object bean, String name) {
    if (bean.getClass().isAnnotationPresent(Transactional.class)) {
        // Создаём прокси с транзакциями
        return proxyFactory.createProxy(bean);
    }
    return bean;  // Обычный бин без изменений
}

Кастомные аннотации

// Своя аннотация
@Target(METHOD)
@Retention(RUNTIME)
public @interface LogExecution { }

// BPP для логирования
@Component
public class LoggingBPP implements BeanPostProcessor {
    public Object postProcessAfterInitialization(Object bean, String name) {
        // Создаём прокси для логирования методов с @LogExecution
        return LoggingProxy.create(bean);
    }
}

BPP vs BeanFactoryPostProcessor

BeanFactoryPostProcessor:
  → Работает с BeanDefinition (до создания бинов)
  → Меняет рецепты
  
BeanPostProcessor:
  → Работает с экземплярами бинов
  → Меняет объекты

---

🔴 Senior Level

BPP vs @Aspect: что выбрать

BPP работает на уровне создания бинов (один раз при старте). Используйте для: регистрации бинов, изменения структуры, оборачивания в прокси.

@Aspect работает на уровне вызовов методов (при каждом вызове). Используйте для: логирования, транзакций, кэширования, мониторинга.

Для application-кода обычно достаточно @Aspect. Кастомные BPP нужны редко — в основном при написании библиотек.

Когда НЕ использовать кастомный BPP

1. Application-код — обычно достаточно @Aspect или стандартных аннотаций
2. Простое логирование — используйте @Aspect + @Around
3. Изменение одного бина — лучше отредактировать сам бин или использовать @Bean метод

InstantiationAwareBeanPostProcessor

Расширенная версия BPP, которая позволяет вмешаться ЕЩЁ ДО создания объекта (postProcessBeforeInstantiation) и СРАЗУ ПОСЛЕ конструктора, но ДО внедрения зависимостей (postProcessAfterInstantiation).

// Расширенный BPP:
public class MyBPP implements InstantiationAwareBeanPostProcessor {
    
    // ДО создания объекта
    public Object postProcessBeforeInstantiation(Class<?> beanClass, String name) {
        // Можно вернуть прокси вместо создания реального объекта
        return null;  // null = создать как обычно
    }
    
    // ПОСЛЕ конструктора, ДО внедрения зависимостей
    public boolean postProcessAfterInstantiation(Object bean, String name) {
        return true;  // true = продолжать внедрение
    }
}

Ранняя инициализация BPP

Если BPP зависит от MyService:
  → MyService создаётся ДО регистрации всех BPP
  → MyService может не получить прокси!
  
Решение:
  → @Lazy зависимости в BPP
  → Или независимые BPP

BPP Ordering

@Order(1)
public class FirstBPP implements BeanPostProcessor { }

@Order(2)
public class SecondBPP implements BeanPostProcessor { }

→ Порядок важен!
→ Первый BPP может заменить бин → второй получит уже заменённый

Production Experience

Реальный сценарий: кастомная аннотация @Cache

// Своя аннотация @CustomCache
@CustomCache(ttl = 3600)
public Data getData() { }

// BPP создаёт прокси с кэшированием
// → Вызов → проверка кэша → если нет → метод → сохранить в кэш

Best Practices

1. BPP → расширение Spring под свои нужды
2. postProcessAfterInitialization → создание прокси
3. @Order → управление порядком
4. @Lazy → избегайте ранней инициализации
5. Не проксируйте BPP → они создаются рано
6. InstantiationAwareBPP → контроль до создания

Резюме для Senior

• BPP → изменение бинов после создания
• Proxy создаётся в postProcessAfterInitialization
• InstantiationAwareBPP → контроль ДО создания
• Order → важен при нескольких BPP
• Ранняя инициализация → может сломать прокси
• BFPP vs BPP → мета-данные vs экземпляры

---

🎯 Шпаргалка для интервью

Обязательно знать:

• BPP (BeanPostProcessor) — механизм Spring для изменения/оборачивания бинов после создания
• Два метода: postProcessBeforeInitialization() (до @PostConstruct) и postProcessAfterInitialization() (после, здесь создаются прокси!)
• Через BPP работают ВСЕ Spring-аннотации, добавляющие поведение: @Transactional, @Async, @Cacheable, @Aspect
• BPP vs BFPP: BPP работает с экземплярами бинов, BFPP — с BeanDefinition (до создания бинов)
• InstantiationAwareBeanPostProcessor — расширенная версия: контроль ДО создания и ПОСЛЕ конструктора, но ДО DI
• Порядок BPP через @Order важен — первый может заменить бин, второй получит уже заменённый
• Для application-кода обычно достаточно @Aspect; кастомные BPP нужны редко (в основном для библиотек)
• Ранняя инициализация: если BPP зависит от бина, тот может не получить прокси — используйте @Lazy

Частые уточняющие вопросы:

• Где создаётся прокси для @Transactional? В postProcessAfterInitialization() — после @PostConstruct.
• Когда выбрать BPP vs @Aspect? @Aspect — для application-кода (логирование, мониторинг). BPP — для библиотек, регистрации бинов, изменения структуры.
• Что возвращает postProcessBeforeInstantiation? Можно вернуть прокси вместо создания объекта, или null — тогда Spring создаст как обычно.
• Почему BPP нельзя проксировать? Они создаются рано в жизненном цикле контейнера — могут не получить свою прокси-обёртку.

Красные флаги (НЕ говорить):

• «BPP — это основной инструмент для application-кода» (для приложения обычно хватает @Aspect, BPP — для библиотек)
• «BPP и BFPP — одно и то же» (BFPP меняет BeanDefinition до создания, BPP меняет экземпляры после)
• «Порядок BPP не имеет значения» (критически важен — первый BPP может заменить бин)
• «Можно свободно инжектить бины в BPP» (вызывает раннюю инициализацию, ломает прокси)

Связанные темы:

• [[6. Что такое Bean Lifecycle]]
• [[7. Какие этапы жизненного цикла Bean]]
• [[9. Что делают методы с аннотацией @PostConstruct и @PreDestroy]]
• [[4. Что такое Bean в Spring]]
• [[1. Что такое Dependency Injection]]