Что теряется при использовании @Component вместо @Bean

@Component vs @Bean: в чём разница и что теряется

На первый взгляд оба подхода позволяют регистрировать бины в Spring контейнере, но @Bean имеет заметные преимущества, которые теряются при использовании @Component.

Основная разница

@Component — аннотация на классе, указывает Spring: "Этот класс является бином, сканируй его автоматически".

@Component
public class UserService {
  public void createUser(String name) {
    System.out.println("User created: " + name);
  }
}

@Bean — аннотация на методе в @Configuration классе, явно указываем как создавать объект.

@Configuration
public class AppConfig {
  @Bean
  public UserService userService() {
    return new UserService();
  }
}

Что теряется с @Component

1. Контроль над инстанцированием

С @Component нельзя передать параметры при создании:

// ❌ С @Component — только конструктор с инъекцией
@Component
public class DatabaseConnection {
  public DatabaseConnection() {
    // Нельзя передать url, user, password
  }
}

// ✅ С @Bean — полный контроль
@Configuration
public class AppConfig {
  @Bean
  public DatabaseConnection databaseConnection() {
    // Можно передать любые параметры
    return new DatabaseConnection(
      "jdbc:postgres://localhost:5432/mydb",
      "admin",
      "password123"
    );
  }
}

2. Инициализация сторонних библиотек

Если нужно работать с классом, который не твой (внешняя библиотека), то @Component не поможет:

// ❌ Невозможно, класс находится в другой библиотеке
@Component
public class ObjectMapper { }

// ✅ С @Bean создаём бин для класса из библиотеки
@Configuration
public class AppConfig {
  @Bean
  public ObjectMapper objectMapper() {
    ObjectMapper mapper = new ObjectMapper();
    mapper.registerModule(new JavaTimeModule());
    mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);
    return mapper;
  }
}

3. Условная регистрация

с @Component сложнее сделать условную регистрацию:

// @Component не поддерживает сложную логику

// ✅ С @Bean можешь использовать любые условия
@Configuration
public class AppConfig {
  @Bean
  @ConditionalOnProperty(name = "app.cache.enabled", havingValue = "true")
  public CacheManager cacheManager() {
    return new ConcurrentMapCacheManager();
  }
  
  @Bean
  @ConditionalOnProperty(name = "app.cache.enabled", havingValue = "false")
  public CacheManager noCacheManager() {
    return new NoOpCacheManager();
  }
}

4. Разные реализации в зависимости от условий

// ❌ С @Component сложно

// ✅ С @Bean просто
@Configuration
public class AppConfig {
  @Bean
  public PaymentService paymentService(
    @Value("${payment.provider}") String provider) {
    
    if ("stripe".equals(provider)) {
      return new StripePaymentService();
    } else if ("paypal".equals(provider)) {
      return new PayPalPaymentService();
    } else {
      return new MockPaymentService();
    }
  }
}

5. Контроль над жизненным циклом

Возможность явно управлять инициализацией и очисткой:

// С @Component можешь только использовать @PostConstruct/@PreDestroy
@Component
public class DatabaseService {
  @PostConstruct
  public void init() {
    // инициализация
  }
  
  @PreDestroy
  public void cleanup() {
    // очистка
  }
}

// ✅ С @Bean больше гибкости
@Configuration
public class AppConfig {
  @Bean(initMethod = "init", destroyMethod = "cleanup")
  public DatabaseService databaseService() {
    return new DatabaseService();
  }
  
  // Или ещё более явный контроль
  @Bean
  public DatabaseService databaseService2() {
    DatabaseService service = new DatabaseService();
    // До возврата можешь сделать что угодно
    service.configure();
    service.start();
    return service;
  }
}

6. Явные зависимости между бинами

// С @Component зависимости через инъекцию и часто неявны
@Component
public class UserService {
  @Autowired
  private UserRepository repo; // неявная зависимость
}

// ✅ С @Bean зависимости явны в сигнатуре метода
@Configuration
public class AppConfig {
  @Bean
  public UserRepository userRepository(DataSource dataSource) {
    // Видно, что UserRepository зависит от DataSource
    return new UserRepository(dataSource);
  }
  
  @Bean
  public UserService userService(UserRepository repo) {
    // Видно, что UserService зависит от UserRepository
    return new UserService(repo);
  }
}

7. Профили (profiles)

// С @Component нужно помнить про @Profile
@Component
@Profile("prod")
public class ProductionEmailService implements EmailService { }

// ✅ С @Bean обычно более читаемо
@Configuration
public class AppConfig {
  @Bean
  @Profile("prod")
  public EmailService productionEmailService() {
    return new ProductionEmailService();
  }
  
  @Bean
  @Profile("test")
  public EmailService testEmailService() {
    return new TestEmailService();
  }
}

8. Проксирование и CGLIB

// ❌ С @Component Spring создаёт прокси
// Если класс final или method final, проксирование может не сработать
@Component
public final class Service { // final — проблема
  public final void doSomething() { }
}

// ✅ С @Bean ты контролируешь объект
@Configuration
public class AppConfig {
  @Bean
  public Service service() {
    // Ты сам решаешь как создавать объект
    return new Service();
  }
}

Сравнительная таблица

Когда использовать

@Component:

• Собственные классы приложения
• Простые случаи без специальной конфигурации
• Когда контроль над инстанцированием не нужен

@Bean:

• Классы из сторонних библиотек
• Сложная инициализация
• Разные реализации в зависимости от условий
• Когда нужна явность и контроль
• Production code с высокими требованиями к качеству

Вывод

@Bean теряет в простоте (чуть больше кода), но выигрывает в гибкости, явности и контроле. Для production кода обычно рекомендуется предпочитать @Bean для конфигурирования.