Как правильно добавлять зависимости в классы, которые зависят от других классов, а не от интерфейсов?

**Какие альтернативы существуют для внедрения зависимости директории в класс FilePatcher вместо использования @Value, если нельзя заранее определить директорию в application.properties? Как оправдано использование оператора new для создания объекта FilePatcher с учетом того, что остальные зависимости внедряются через @Autowired в CommitManager? Существуют ли конвенции или рекомендации, касающиеся правильного внедрения зависимостей в Spring-приложениях?**
  • 16 апреля 2024 г. 15:30
Ответы на вопрос 2
Для правильного внедрения зависимостей в классы, которые зависят от других классов, а не от интерфейсов, рекомендуется использовать принцип инверсии управления (IoC) и внедрение зависимостей (DI). В Spring Framework это обычно реализуется с помощью аннотации @Autowired или с помощью конструктора.

Чтобы внедрить зависимость дириктории в класс FilePatcher, можно использовать конструктор, в котором передается директория в качестве параметра. Например:

```java
@Component
public class FilePatcher {

    private String directory;

    @Autowired
    public FilePatcher(@Value("{directory}") String directory) {
        this.directory = directory;
    }
}
```

Если нельзя заранее определить директорию в application.properties, можно использовать другие способы передачи этого значения, например, через конфигурационный класс или через параметры методов.

Основное оправдание использования оператора new для создания объекта FilePatcher в классе CommitManager в Spring-приложении - это, возможно, создание необходимого объекта в одиночном экземпляре или в определенном контексте. В остальных случаях рекомендуется использовать механизм внедрения зависимостей Spring Framework.

Существует ряд конвенций и рекомендаций по правильному внедрению зависимостей в Spring-приложениях:

1. Использование аннотаций для внедрения зависимостей (@Autowired, @Value) вместо создания объектов через оператор new.
2. Использование конструктора для внедрения обязательных зависимостей, чтобы избежать создания классов в неполно инициализированном состоянии.
3. Использование правильной структуры проекта, разделение бизнес-логики и слоя доступа к данным для более гибкой и простой поддержки кода.
4. Предпочтение внедрения зависимостей перед жесткой привязкой классов друг к другу.
5. Организация конфигураций и бинов Spring в соответствии с принципом единственной ответственности.

Следуя этим рекомендациям, можно создать чистый, гибкий и легко поддерживаемый код в Spring-приложениях.
Есть ли альтернативы, кроме как отпустить идею с определением FilePatcher как бина?

Вы можете определить его как бин чуть позже - в момент, когда вам становится известен directory. FilePatcher надо будет инжектить с аннотацией @Lazy .

Похожие вопросы