Какие паттерны проектирования используются в Spring

Что проверяют

Понимаете ли вы, как Spring устроен внутри, а не просто знаете названия паттернов. Самый частый уточняющий вопрос: почему @Transactional не срабатывает при вызове метода из того же класса.

Как отвечать

Называйте паттерн вместе с конкретным классом:

• IoC и Dependency Injection: основа контейнера, зависимости приходят через конструктор, и класс не знает, откуда они;
• Singleton: скоуп бина по умолчанию. Но это один экземпляр на определение бина в контейнере, а не классический GoF: два бина одного класса вполне возможны. Рядом есть prototype, request, session;
• Factory: BeanFactory и ApplicationContext, методы @Bean, интерфейс FactoryBean для сложной сборки;
• Proxy: на нём держатся @Transactional, @Cacheable, @Async и Spring AOP. Для интерфейсов возможен JDK dynamic proxy, иначе CGLIB-подкласс, Spring Boot по умолчанию берёт CGLIB;
• Template Method и Callback: JdbcTemplate, TransactionTemplate, RestTemplate. Для нового HTTP-кода с Spring 6.1 есть RestClient;
• Observer: ApplicationEventPublisher, @EventListener, @TransactionalEventListener;
• Front Controller и Adapter: DispatcherServlet принимает все запросы, HandlerAdapter вызывает обработчики разных типов;
• Strategy: PlatformTransactionManager с реализациями под JDBC и JPA, ResourceLoader;
• Chain of Responsibility: цепочка фильтров Spring Security, SecurityFilterChain;
• Builder: UriComponentsBuilder, RestClient.builder(), построители запросов в MockMvc.

Где спотыкаются

Не знают про самовызов. Метод, вызванный через this, минует прокси, и @Transactional или @Cacheable на нём не работают. Лечится выносом в другой бин.

Считают singleton-бин потокобезопасным. Контейнер создаёт один экземпляр, но изменяемое поле в нём разделяют все потоки.

Перечисляют паттерны без примеров из фреймворка. Список «Singleton, Factory, Proxy» без DispatcherServlet и JdbcTemplate звучит заученно.