Какие знаешь способы решения проблемы нескольких кандидатов при внедрении зависимостей в Spring?

# Способы решения проблемы нескольких кандидатов при внедрении зависимостей в Spring

Эта проблема возникает, когда в контексте Spring существует несколько бинов, реализующих один и тот же интерфейс. Spring не знает, какой именно бин внедрить. Существует несколько способов решения.

Проблема: Ambiguity

public interface PaymentService {
    void pay(double amount);
}

@Component
public class StripePaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via Stripe");
    }
}

@Component
public class PayPalPaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via PayPal");
    }
}

@Service
public class OrderService {
    private final PaymentService paymentService;  // ❌ Какой бин внедрить?
    
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

При такой конфигурации Spring выбросит ошибку:

NoUniqueBeanDefinitionException: 
No qualifying bean of type 'com.example.PaymentService' available: 
expected single matching bean but found 2: stripePaymentService, payPalPaymentService

Способ 1: @Primary (Приоритет)

Отметить один из бинов как первичный (используется по умолчанию):

public interface PaymentService {
    void pay(double amount);
}

@Component
@Primary  // ← Этот бин будет использован по умолчанию
public class StripePaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via Stripe");
    }
}

@Component
public class PayPalPaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via PayPal");
    }
}

@Service
public class OrderService {
    private final PaymentService paymentService;
    
    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;  // StripePaymentService будет внедрена
    }
}

Преимущества:

• Простая реализация
• Подходит когда есть явный "основной" вариант

Недостатки:

• Только один вариант может быть primary
• Не гибко, если нужны другие варианты

Способ 2: @Qualifier (Именованные ссылки)

Отметить конкретный бин по имени и явно указать его при внедрении:

public interface PaymentService {
    void pay(double amount);
}

@Component
@Qualifier("stripe")  // Даем имя бину
public class StripePaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via Stripe");
    }
}

@Component
@Qualifier("paypal")  // Даем имя бину
public class PayPalPaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via PayPal");
    }
}

@Service
public class OrderService {
    private final PaymentService paymentService;
    
    // Явно указываем какой бин использовать
    public OrderService(@Qualifier("stripe") PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Также можно использовать имя класса по умолчанию:

@Service
public class OrderService {
    private final PaymentService paymentService;
    
    // Использует имя класса: stripePaymentService
    public OrderService(@Qualifier("stripePaymentService") PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

Iли для field injection:

@Service
public class OrderService {
    @Autowired
    @Qualifier("paypal")
    private PaymentService paymentService;
}

Преимущества:

• Гибкий подход
• Можно указать любой из нескольких бинов
• Явно видно в коде какой бин используется

Недостатки:

• Нужно повторять @Qualifier везде
• Магические строки (слабо типизировано)

Способ 3: Кастомная аннотация (Лучший подход)

Создать собственную аннотацию, расширяющую @Qualifier:

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface Stripe {
}

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface PayPal {
}

// Использование
@Component
@Stripe
public class StripePaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via Stripe");
    }
}

@Component
@PayPal
public class PayPalPaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via PayPal");
    }
}

@Service
public class OrderService {
    private final PaymentService paymentService;
    
    public OrderService(@Stripe PaymentService paymentService) {
        this.paymentService = paymentService;  // Типизировано, не строки!
    }
}

Преимущества:

• Типизировано (нет магических строк)
• Легко читать и рефакторить
• IDE поддерживает find/replace
• Самое аккуратное решение

Недостатки:

• Нужно создавать отдельные аннотации

Способ 4: Внедрить все реализации (ObjectProvider или List)

Внедрить все бины сразу и выбрать нужный во время выполнения:

@Service
public class OrderService {
    private final Map<String, PaymentService> paymentServices;
    
    // Внедрить все реализации
    public OrderService(Map<String, PaymentService> paymentServices) {
        this.paymentServices = paymentServices;
    }
    
    public void processOrder(String paymentMethod, double amount) {
        PaymentService service = paymentServices.get(paymentMethod);
        if (service != null) {
            service.pay(amount);
        }
    }
}

// Вызов
orderService.processOrder("stripe", 100.0);  // Использует StripePaymentService
orderService.processOrder("paypal", 50.0);   // Использует PayPalPaymentService

Или с использованием List:

@Service
public class OrderService {
    private final List<PaymentService> paymentServices;
    
    public OrderService(List<PaymentService> paymentServices) {
        this.paymentServices = paymentServices;  // Все реализации
    }
    
    public void processAllPayments(double amount) {
        for (PaymentService service : paymentServices) {
            service.pay(amount);
        }
    }
}

Или с ObjectProvider (более гибко):

@Service
public class OrderService {
    private final ObjectProvider<PaymentService> paymentServices;
    
    public OrderService(ObjectProvider<PaymentService> paymentServices) {
        this.paymentServices = paymentServices;
    }
    
    public void processOrder(double amount) {
        // Получить primary, если есть
        PaymentService service = paymentServices.getIfAvailable();
        if (service != null) {
            service.pay(amount);
        }
        
        // Или итерировать все
        paymentServices.forEach(s -> s.pay(amount));
    }
}

Преимущества:

• Очень гибко
• Не нужно заранее знать какую реализацию использовать
• Подходит для plugin-архитектур

Недостатки:

• Логика выбора разбросана по коду
• Нужно обрабатывать случаи когда бина нет

Способ 5: @ConditionalOnProperty (Конфигурация)

Включать/выключать бины на основе properties:

@Component
@ConditionalOnProperty(
    name = "payment.provider",
    havingValue = "stripe"
)
public class StripePaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via Stripe");
    }
}

@Component
@ConditionalOnProperty(
    name = "payment.provider",
    havingValue = "paypal"
)
public class PayPalPaymentService implements PaymentService {
    @Override
    public void pay(double amount) {
        System.out.println("Paying " + amount + " via PayPal");
    }
}

// application.properties
// payment.provider=stripe

Преимущества:

• Конфигурируется через properties
• Подходит для выбора реализации при развертывании
• Только один бин будет создан

Недостатки:

• Нужно менять конфиг для смены реализации

Способ 6: @Configuration класс (Явное создание)

Явно создавать бины в конфигурационном классе:

@Configuration
public class PaymentConfig {
    
    @Bean(name = "stripe")
    public PaymentService stripePaymentService() {
        return new StripePaymentService();
    }
    
    @Bean(name = "paypal")
    public PaymentService paypalPaymentService() {
        return new PayPalPaymentService();
    }
    
    @Bean
    public OrderService orderService(@Qualifier("stripe") PaymentService paymentService) {
        return new OrderService(paymentService);
    }
}

Преимущества:

• Четко видна конфигурация
• Полный контроль над созданием бинов
• Подходит для конфигурирования внешних библиотек

Недостатки:

• Нужно писать больше кода
• Нарушает концепцию component scanning

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

Рекомендация

Для большинства случаев используй комбинацию подходов:

// Для prod кода - кастомные аннотации
@Component
@Stripe  // Типизировано
public class StripePaymentService implements PaymentService { }

// Для выбора при запуске - конфигурация
@Bean
@ConditionalOnProperty(name = "payment.provider", havingValue = "stripe")
public PaymentService paymentService() {
    return new StripePaymentService();
}

// Для раннего обнаружения ошибок - primary
@Component
@Primary  // По умолчанию
public class DefaultPaymentService implements PaymentService { }

Это обеспечит чистоту кода, типизацию и гибкость конфигурации.