Что будет если пометить метод экземпляра класса @Bean?

# Что будет если пометить метод экземпляра класса @Bean?

Коротко

@Bean на методе экземпляра работает, но это является анти-паттерном. Spring проксирует класс и создаёт bean, но возникают неожиданные проблемы.

Как это работает

@Configuration
public class AppConfig {
    @Bean
    public UserRepository userRepository() { // ✅ Правильно - static не требуется
        return new UserRepository();
    }
}

// Это одно и то же как:
@Configuration
public class AppConfig {
    private String configName = "myConfig"; // экземплярная переменная
    
    @Bean
    public UserService userService() { // Метод экземпляра
        // Может использовать this.configName
        return new UserService(configName);
    }
}

Spring инстанцирует сам AppConfig как bean, а потом вызывает метод userService() на экземпляре.

Примеры проблем

1. Неявная зависимость на состояние конфига

@Configuration
public class AppConfig {
    private String databaseUrl = "jdbc:mysql://localhost/db";
    
    @Bean
    public DataSource dataSource() {
        // Неявно использует this.databaseUrl
        return createDataSource(databaseUrl);
    }
    
    @Bean
    public UserRepository userRepository() {
        // Может читать this.databaseUrl если потребуется
        return new UserRepository();
    }
}

Проблема: Если кто-то меняет databaseUrl, это влияет на все beans, которые зависят от этого состояния.

2. Проблемы с многопоточностью

@Configuration
public class AppConfig {
    private int beanCount = 0; // статус, который меняется
    
    @Bean
    public UserService userService() {
        beanCount++; // Race condition!
        System.out.println("Created bean #" + beanCount);
        return new UserService();
    }
}

Проблема: Если ApplicationContext инициализируется в многопоточной среде, может быть race condition на переменной beanCount.

3. Сложность с proxy-сервисом

Spring использует CGLIB proxy для конфигурационных классов:

@Configuration
public class AppConfig {
    @Bean
    public DatabaseConfig databaseConfig() {
        return new DatabaseConfig();
    }
    
    @Bean
    public UserRepository userRepository() {
        // Spring проксирует AppConfig, поэтому вызов idempotentный
        // userRepository() будет вызвана один раз, результат закэширован
        return new UserRepository(databaseConfig()); // ✅ Returns cached bean
    }
}

Интерпретатор кода выше работает хорошо, но это скрывает сложность.

4. Сложность тестирования

@Configuration
public class AppConfig {
    private Environment environment; // Зависимость на Environment
    
    @Bean
    public ApiClient apiClient() {
        String apiUrl = environment.getProperty("api.url");
        return new ApiClient(apiUrl);
    }
}

// При тестировании нужно мокировать весь AppConfig
@Test
public void testApiClient() {
    AppConfig config = new AppConfig();
    // Как установить environment?
    // Нельзя просто новый экземпляр создать
}

Правильный подход

✅ Вариант 1: статический метод (если переменная не нужна)

@Configuration
public class AppConfig {
    @Bean
    public static UserRepository userRepository() { // static
        return new UserRepository();
    }
}

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

• Явно указывает что это не зависит от состояния
• Проще тестировать
• Нет неожиданных побочных эффектов

✅ Вариант 2: передать зависимость как параметр

@Configuration
public class AppConfig {
    @Bean
    public UserRepository userRepository(DatabaseConfig dbConfig) {
        // Явная зависимость через параметр
        // Spring автоматически инжектит
        return new UserRepository(dbConfig);
    }
    
    @Bean
    public DatabaseConfig databaseConfig() {
        return new DatabaseConfig();
    }
}

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

• Явные зависимости
• Легко тестировать
• Видно в сигнатуре метода что нужно

✅ Вариант 3: использовать @ConfigurationProperties

@Configuration
@ConfigurationProperties(prefix = "app.db")
public class DatabaseProperties {
    private String url;
    private String username;
    // getters/setters
}

@Configuration
public class AppConfig {
    @Bean
    public UserRepository userRepository(DatabaseProperties props) {
        return new UserRepository(props.getUrl());
    }
}

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

• Конфигурация отделена от logic
• Типизирована
• Легко тестировать

Когда это может быть в порядке (редко)

@Configuration
public class AppConfig {
    private final Environment environment; // Фinal, setter нет
    
    public AppConfig(Environment environment) {
        this.environment = environment; // Инжектиться через конструктор
    }
    
    @Bean
    public ApiClient apiClient() {
        String url = environment.getProperty("api.url");
        return new ApiClient(url);
    }
}

Здесь это может быть OK потому что:

• environment - final и immutable
• Инжектится в конструктор, не меняется после инициализации
• Нет race conditions

Но даже здесь лучше передать через параметр метода:

@Configuration
public class AppConfig {
    @Bean
    public ApiClient apiClient(Environment environment) {
        String url = environment.getProperty("api.url");
        return new ApiClient(url);
    }
}

Что происходит под капотом

Когда Spring видит @Bean на методе экземпляра:

1. Создаёт CGLIB proxy класса AppConfig
2. При вызове userRepository() - перехватывает вызов
3. Проверяет есть ли результат в кэше beans
4. Если есть - возвращает кэшированный bean
5. Если нет - вызывает реальный метод и кэширует результат

// Что делает Spring под капотом:
public class AppConfigProxy extends AppConfig {
    private Map<String, Object> beanCache = new HashMap<>();
    
    @Override
    public UserRepository userRepository() {
        if (!beanCache.containsKey("userRepository")) {
            beanCache.put("userRepository", super.userRepository());
        }
        return (UserRepository) beanCache.get("userRepository");
    }
}

Резюме и лучшие практики

Conclusion

Использование @Bean на методе экземпляра с состоянием - это технически работает, но это анти-паттерн. Вместо этого:

1. Используй параметры метода для explicit зависимостей
2. Используй static методы если состояние не нужно
3. Используй @ConfigurationProperties для конфигурации
4. Избегай mutable state в @Configuration классах

Это делает код более читаемым, тестируемым и безопасным в многопоточной среде.