Какие существуют варианты создания бинов в Spring

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

Знаете ли вы, чем аннотация на классе отличается от метода в конфигурации, и понимаете ли, когда какой способ уместен. Заодно смотрят, работали ли вы с чужим кодом, где всё уже настроено не вами.

Как отвечать

Способов три, и они решают разные задачи.

1. Аннотации-стереотипы на своём классе. @Component и его специализации @Service, @Repository, @Controller. Работают вместе со сканированием пакетов: Spring сам находит класс и создаёт бин.

@Service
public class PaymentService { }

Подходит для кода, который пишете вы. Специализации не просто синонимы: @Repository, например, включает перевод исключений персистентности.

2. Метод с @Bean в классе @Configuration. Единственный способ зарегистрировать класс, который вам не принадлежит: чужую библиотеку аннотацией не пометить.

@Configuration
public class AppConfig {
    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder.setConnectTimeout(Duration.ofSeconds(5)).build();
    }
}

Здесь же удобно собирать бин из нескольких зависимостей и настраивать его руками.

3. XML-конфигурация. Историческая, встречается в старых проектах. Знать стоит, чтобы читать легаси, но новый код так не пишут.

Дальше почти всегда спрашивают про область видимости (@Scope: singleton по умолчанию, prototype, request), про условную регистрацию (@Conditional, @Profile) и про то, как разрешается конфликт нескольких кандидатов (@Primary, @Qualifier).

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

Не могут объяснить, зачем @Bean, если есть @Component. Ответ: чужой класс пометить нечем.

Путают singleton в Spring и синглтон как шаблон: в Spring это один экземпляр на контейнер, а не на JVM.

Забывают, что бины по умолчанию создаются при старте контекста, и что внедрение через конструктор предпочтительнее полевого: оно делает зависимости явными и позволяет объявить поле final.