Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 Теги: dependency injection, di, spring, java, циклическая зависимость, di через параметры конструктора, di через поля, @postconstruct, nullpointerexception, зависимости в бин, spring context, di через сеттеры

2 Dependency Injection в Spring можно осуществлять различными способами. Рассмотрим плюсы и минусы данных подходов.

3 <h2>Например, рассмотрим DI через параметры конструктора</h2>

4 @Service public class MyService { private Dependency dependency; @Autowired public MyService(Dependency dependency) { this.dependency = dependency; } }Данный подход является рекомендованным. Разберёмся с некоторыми ситуациями, где DI через параметры конструктора может выглядеть не самым лучшим образом, и выясним, причины этого:

5 Чуешь, чем пахнет?Появляется большое число параметров конструктора, что является "запахом плохого кода". Если для создания бина требуется множество зависимостей, то DI через конструктор, как ни странно, ни при чём. Если в классе большое число зависимостей, то это говорит, скорее о неправильном дизайне самого сервиса.

6 Как пони по кругуЕсли между классами есть циклическая зависимость, то DI через конструктор не получится организовать. Действительно, это так, но если появилась циклическая зависимость между классами, то это, скорее, неправильное разделение ответственности между сервисами.

7 У DI через параметры конструктора, есть безусловные плюсы:

8 <li>в любой момент времени вы всегда получите готовый к работе класс со всеми зависимостями;</li>

9 <li>данные классы можно просто тестировать как обычные Java-классы и без поднятия контекста для тестирования;</li>

10 <li>в unit-тестах вы не сможете забыть добавить какую-либо зависимость, так как она будет требоваться на уровне компиляции.</li>

11 С циклическими зависимостями можно, в частности, бороться с помощью

12 <h2>DI через поля:</h2>

13 @Service public class MyService { @Autowired private Dependency dependency; }Несмотря на действительно минимальное количество кода, этот подход обладает одним большим недостатком. Данный класс нельзя просто протестировать, не поднимая Spring Context. Если для контроллеров и других классов в любом случае придётся его поднимать, то для бизнес-сервисов это излишне.

14 <h2>Ну и DI через сеттеры</h2>

15 @Service public class MyService { private Dependency dependency; @Autowired public void setDependency(Dpendency dependency) { this.dependency = dependency; } }В данном случае тестировать эти классы почти так же просто, как и в случае DI через параметры конструктора. Но в тестах очень легко забыть проставить зависимость, не вызвав свежедобавленный сеттер.

16 Этот способ обладает одним серьёзным недостатком: до того момента, как Spring проставит все зависимости в бин, экземпляр класса находится в некорректном состоянии. И обращение к зависимостям может привести кNullPointerException. Для того, чтобы сделать какие-то действия после того, как все зависимости будут инъектированы, используют аннотацию@PostConstruct:

17 @Service public class MyService { private Dependency dependency;@Autowired public void setDependency(Dpendency dependency) { this.dependency = dependency; }

18 @PostConstruct public void init() { this.dependency.doSomething(); } }

19 Остались вопросы? Задавайте в комментариях!