Как обеспечить использование пользователем старого бина в библиотеке при добавлении бина с таким же типом

# Как обеспечить использование старого бина при добавлении нового бина с таким же типом

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

Проблема

// Старая версия библиотеки (v1.0)
public class MyLibraryAutoConfig {
    @Bean
    public DataValidator oldValidator() {
        return new OldValidator();
    }
}

// Новая версия библиотеки (v2.0)
public class MyLibraryAutoConfig {
    @Bean
    public DataValidator oldValidator() {
        return new OldValidator();
    }
    
    @Bean
    public DataValidator newValidator() {
        return new NewValidator();
    }
    // Теперь есть две реализации DataValidator!
    // Spring не знает, какую использовать → NoUniqueBeanDefinitionException
}

// Код пользователя
@Service
public class MyService {
    @Autowired
    private DataValidator validator; // Ошибка! Какой validator выбрать?
}

Решение 1: @Primary (рекомендуется)

Отмечаем старый бин как основной:

@Configuration
public class DataValidationConfig {
    @Bean
    @Primary // Используется по умолчанию
    public DataValidator oldValidator() {
        return new OldValidator();
    }
    
    @Bean
    public DataValidator newValidator() {
        return new NewValidator();
    }
}

// Использование
@Service
public class MyService {
    @Autowired
    private DataValidator validator; // Получит OldValidator (Primary)
}

Пользователи могут явно выбрать новый бин, если хотят:

@Service
public class MyService {
    @Autowired
    @Qualifier("newValidator") // Явно выбираем новый
    private DataValidator validator;
}

Решение 2: @ConditionalOnMissingBean

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

@Configuration
public class DataValidationConfig {
    
    @Bean
    @ConditionalOnMissingBean
    public DataValidator validator() {
        // Создаём бин только если его ещё нет
        return new NewValidator();
    }
}

// Пользователь может переопределить:
@Configuration
public class UserConfig {
    @Bean
    public DataValidator validator() { // Теперь его бин будет использован
        return new CustomValidator();
    }
}

Решение 3: Deprecated с рефакторингом

Помечаем старый класс как deprecated и отстраиваем документацию:

/**
 * @deprecated Используйте {@link NewValidator} вместо этого.
 * Будет удалён в версии 3.0
 * 
 * <pre>
 * // Старый код
 * DataValidator validator = new OldValidator();
 * 
 * // Новый код
 * DataValidator validator = new NewValidator();
 * </pre>
 */
@Deprecated(since = "2.0", forRemoval = true)
public class OldValidator implements DataValidator {
    // Реализация
}

SuppressWarnings для пользователей:

@Service
public class MyService {
    @Autowired
    @SuppressWarnings("deprecation")
    private OldValidator oldValidator; // Работает, но показывает предупреждение
}

Решение 4: Абстрактный класс с implements

Оба валидатора реализуют один интерфейс, но используется полиморфизм:

public interface DataValidator {
    void validate(String data);
}

// Старая реализация
public class OldValidator implements DataValidator {
    @Override
    public void validate(String data) {
        // Старая логика валидации
    }
}

// Новая реализация
public class NewValidator implements DataValidator {
    @Override
    public void validate(String data) {
        // Улучшенная логика валидации
    }
}

@Configuration
public class ValidationConfig {
    @Bean
    @Primary
    public DataValidator validator(Environment env) {
        String strategy = env.getProperty("validation.strategy", "old");
        
        if ("new".equals(strategy)) {
            return new NewValidator();
        }
        return new OldValidator();
    }
}

Пользователь может выбрать через properties:

# application.properties
validation.strategy=old  # Продолжает использовать старый
# или
validation.strategy=new  # Переходит на новый

Решение 5: ObjectProvider (лучший для гибкости)

Даём пользователю выбор без ошибок:

@Configuration
public class DataValidationConfig {
    
    @Bean
    public DataValidator oldValidator() {
        return new OldValidator();
    }
    
    @Bean
    @Primary // Old как дефолт
    public DataValidator defaultValidator(ObjectProvider<DataValidator> oldValidator) {
        return oldValidator.getIfAvailable(() -> new NewValidator());
    }
}

// Использование
@Service
public class MyService {
    private final DataValidator validator;
    
    public MyService(ObjectProvider<DataValidator> validators) {
        // Получит Old (Primary), но может безопасно работать с New
        this.validator = validators.getIfAvailable(
            () -> new NewValidator()
        );
    }
}

Решение 6: Стратегия с enum

Даём пользователю явный выбор:

public enum ValidatorStrategy {
    OLD(OldValidator::new),
    NEW(NewValidator::new);
    
    private final Supplier<DataValidator> factory;
    
    ValidatorStrategy(Supplier<DataValidator> factory) {
        this.factory = factory;
    }
    
    public DataValidator create() {
        return factory.get();
    }
}

@Configuration
public class DataValidationConfig {
    
    @Bean
    public DataValidator validator(@Value("${validator.strategy:OLD}") ValidatorStrategy strategy) {
        return strategy.create();
    }
}

// application.properties
validator.strategy=OLD  # или NEW

Решение 7: Adapter паттерн

Создаём адаптер для обратной совместимости:

// Новая реализация
public class NewValidator implements DataValidator {
    public ValidationResult validateV2(String data) {
        // Новая логика
    }
}

// Адаптер для старого интерфейса
public class ValidatorAdapter implements OldDataValidator {
    private final DataValidator newValidator;
    
    public ValidatorAdapter(DataValidator newValidator) {
        this.newValidator = newValidator;
    }
    
    @Override
    public void validate(String data) {
        // Адаптируем новый интерфейс к старому
        newValidator.validate(data);
    }
}

@Configuration
public class LegacyConfig {
    @Bean
    @Primary
    public OldDataValidator legacyValidator(DataValidator newValidator) {
        return new ValidatorAdapter(newValidator);
    }
}

Полный пример: миграция с версии 1.0 на 2.0

// v2.0 конфигурация библиотеки
@Configuration
public class MyLibraryAutoConfig {
    
    // Старый бин с Primary флагом
    @Bean(name = "legacyValidator")
    @Primary
    @ConditionalOnProperty(
        name = "mylib.validator.version",
        havingValue = "1.0",
        matchIfMissing = true // По умолчанию используем старый
    )
    public DataValidator legacyValidator() {
        return new OldValidator();
    }
    
    // Новый бин (активируется только если пользователь явно включит)
    @Bean(name = "newValidator")
    @ConditionalOnProperty(
        name = "mylib.validator.version",
        havingValue = "2.0"
    )
    public DataValidator newValidator() {
        return new NewValidator();
    }
}

// Использование
@Service
public class ValidationService {
    private final DataValidator validator;
    
    // Получит Legacy по умолчанию
    public ValidationService(DataValidator validator) {
        this.validator = validator;
    }
}

// Если пользователь хочет новый, добавляет в application.properties:
// mylib.validator.version=2.0

Best Practices

1. Используй @Primary для обратной совместимости — старый бин остаётся основным
2. Документируй миграцию — покажи пользователям как переходить
3. Логируй предупреждения — говори, что старый бин deprecated
4. Используй @ConditionalOnMissingBean — позволяй переопределять
5. Дай время на миграцию — удаляй старый код только через версии
6. Используй Environment и properties — гибкая конфигурация

Заключение

Для обеспечения использования старого бина при добавлении нового:

• @Primary — отмечаем старый как основной
• @ConditionalOnProperty — позволяем выбирать через конфиг
• ObjectProvider — безопасный доступ с fallback
• @Deprecated — показываем намерение удалить старый
• Документация — объясняем миграционный путь

Это позволяет библиотеке развиваться без breaking changes для пользователей.