Field injection — плохая привычка

1. Field injection: удобный старт

Field injection часто выглядит как самый дружелюбный вход в Spring: добавил аннотацию — и “всё само”. Новичку это напоминает розетку: вот вилка (@Autowired), вот ток (bean), а почему вообще электричество работает — неважно, главное лампочка горит. Проблема в том, что “горит” она до первого серьёзного рефакторинга, юнит-теста или запуска без контейнера.

Самый типичный вид field injection в сервисе выглядит так:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AuditService {

    // Spring подставит зависимость через рефлексию ПОСЛЕ создания объекта
    @Autowired
    private AuditWriter auditWriter;

    public void audit(String message) {
        // Если зависимость не внедрена (например, объект создали через new),
        // то здесь будет NullPointerException
        auditWriter.write(message);
    }
}

Почему это кажется удобным? Потому что в конструкторе ничего писать не надо. У класса есть «бесплатный» пустой конструктор (его даже не видно, но он существует), IDE не подсвечивает ничего красным, и в маленьком примере всё действительно работает: контейнер создаст объект, потом через рефлексию установит поле, и метод audit() вызовет auditWriter.

На этом месте обычно возникает мысль: «Зачем вообще тот длинный конструктор, если можно вот так — два слова и готово?» И вот тут начинается самое интересное. Field injection действительно короче, но эта “экономия букв” покупается за счёт очень конкретных инженерных минусов: контракт класса прячется, объект может существовать в невалидном состоянии, зависимость нельзя сделать final, тестировать неудобнее, а рефакторинг ловит проблемы позже, чем хотелось бы.

2. Field injection скрывает контракт класса

Когда вы открываете файл сервиса, вы хотите за 10 секунд понять две вещи: «что делает класс» и «без чего он не работает». В идеале ответ на второй вопрос — это конструктор. У field injection такого “единого входа” нет: зависимости размазаны по полям, и вам приходится глазами “сканировать” весь верх класса, а иногда и не только верх.

Сравним два варианта на примере сервиса из ContextFlow. Сначала — field injection:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class OrderPlacementService {

    // Зависимости не очевидны: их приходится искать глазами по полям
    @Autowired private OrderIdGenerator orderIdGenerator;
    @Autowired private OrderStore orderStore;
    @Autowired private OrderPricingService pricingService;

    // ...
}

А теперь — constructor injection (тот же смысл, но контракт виден сразу):

import org.springframework.stereotype.Service;

@Service
public class OrderPlacementService {

    // По final видно: зависимость обязательная и фиксируется при создании объекта
    private final OrderIdGenerator orderIdGenerator;
    private final OrderStore orderStore;

    // Конструктор = явный контракт: без этих зависимостей сервис не соберётся
    public OrderPlacementService(OrderIdGenerator orderIdGenerator, OrderStore orderStore) {
        this.orderIdGenerator = orderIdGenerator;
        this.orderStore = orderStore;
    }
}

Чтобы почувствовать разницу, попробуйте чисто мысленно сыграть в игру “я новый разработчик в команде, мне дали тикет на изменение сценария”. В constructor-варианте я мгновенно вижу: этот сервис зависит от OrderIdGenerator и OrderStore. В field-варианте я тоже это увижу… но только если поля лежат рядом, аккуратно оформлены, никто не разбросал их по файлу, никто не добавил ещё пару @Autowired ниже “по ходу дела”.

Вот короткая таблица (это не список ради списка, а “сканер мысли”):

Смешная, но точная аналогия: constructor injection — это когда на коробке написано «для сборки шкафа нужны 8 винтов и 2 двери». Field injection — это когда двери должны приехать “потом”, и вы узнаете об этом, когда уже поставили шкаф в комнату и обнаружили, что он слегка «продувается».

3. Недособранный объект и поздний NullPointerException

Одна из самых неприятных особенностей field injection в том, что объект можно создать обычным new, и Java будет считать, что всё в порядке. Это означает, что “неправильное использование” не ловится компилятором и не выглядит как ошибка на уровне API класса. Ошибка вылезет потом — в виде NullPointerException — и часто в месте, которое вообще не похоже на “ошибку DI”.

Посмотрим на это вживую. Наш AuditService с field injection можно создать так:

public class Demo {
    public static void main(String[] args) {
        // Создали объект вручную — Spring рядом нет
        AuditService service = new AuditService();

        // auditWriter так и останется null, поэтому здесь будет NullPointerException
        service.audit("order created");
    }
}

Да, код компилируется. Да, объект создаётся. И да, при вызове audit() вы получите NullPointerException, потому что auditWriter никто не установил: контейнера Spring рядом нет, а поле приватное.

В constructor-варианте этот сценарий невозможен: вы физически не сможете создать объект без зависимости.

// Зависимость создаём явно (или подставляем заглушку в тесте)
AuditWriter writer = new ConsoleAuditWriter();

// Без writer объект не соберётся — это fail-fast на уровне компиляции/IDE
AuditService service = new AuditService(writer);

Важный момент: «Но ведь мы же в Spring, зачем нам new?» — отличный вопрос. Ответ простой: мы постоянно хотим иметь возможность создать объект вне контейнера, хотя бы в двух жизненных ситуациях. Первая — юнит-тест (мы к нему ещё вернёмся). Вторая — ручная проверка/демо в plain Java, когда вы отлаживаете кусок логики и не хотите поднимать целый контекст.

Чтобы это не звучало как абстракция, вот схема, что реально происходит при field injection в контейнере:

sequenceDiagram
    participant C as Spring Container
    participant S as AuditService
    participant W as AuditWriter

    %% Шаг 1: объект создаётся без зависимостей
    C->>S: new AuditService()
    Note over S: auditWriter = null

    %% Шаг 2: контейнер находит/создаёт нужный bean
    C->>W: get bean AuditWriter

    %% Шаг 3: контейнер заполняет поле через рефлексию
    C->>S: set field auditWriter via reflection
    Note over S: auditWriter != null

    C-->>S: bean ready

Обратите внимание на важную деталь: объект создаётся сначала, а зависимости приходят потом. Это и есть “недособранное состояние”. Внутри Spring это контролируется, но как только объект вытащили из этого “коридора сборки” (например, попытались создать вручную), он снова становится потенциально невалидным.

4. Зависимость нельзя сделать final

final для зависимостей — это не “красота ради красоты”. Это простая и практическая защита: если зависимость обязательна, то после создания объекта она не должна меняться. Это удерживает класс в понятном состоянии, снижает шанс случайных багов и делает чтение проще: если поле final, значит его установили в конструкторе, и оно точно не будет внезапно заменено на что-то другое в середине жизни объекта.

При field injection вы обычно не можете сделать поле final, потому что final надо присвоить в конструкторе (или в инициализаторе), а Spring устанавливает поле позже.

Вот так не получится (и это хорошо, что не получится):

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AuditService {

    // final требует инициализации в конструкторе, а при field injection Spring делает это позже
    @Autowired
    private final AuditWriter auditWriter; // так нельзя

    public void audit(String message) {
        auditWriter.write(message);
    }
}

Из‑за этого многие сервисы с field injection выглядят так:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AuditService {

    // Поле нельзя сделать final -> появляется риск “дополнительной инициализации” где-то ещё
    @Autowired
    private AuditWriter auditWriter; // не final

    public void audit(String message) {
        auditWriter.write(message);
    }
}

«Ну и что, я же не буду его менять» — снова нормальная мысль. Но тут вступает в игру человеческий фактор и рефакторинги. Сегодня вы “не будете менять”, а через три недели кто-то добавит метод setAuditWriterForTest() (да, так тоже бывает), потому что “срочно нужно протестировать”. Или банально кто-то добавит ещё одну точку инициализации, и объект превратится в пазл.

Constructor injection возвращает норму: final-поля, и зависимость фиксируется один раз.

import org.springframework.stereotype.Service;

@Service
public class AuditService {

    // final подчёркивает: зависимость обязательная и неизменяемая после создания
    private final AuditWriter auditWriter;

    public AuditService(AuditWriter auditWriter) {
        // Конструктор — единственное место, где мы “собираем” объект
        this.auditWriter = auditWriter;
    }
}

Это выглядит как “больше кода”, но на практике это меньше неопределённости. А неопределённость — самый дорогой ресурс в команде (после кофе).

5. Юнит-тесты без Spring и рефлексия

Слабое место field injection особенно хорошо видно в юнит-тестах. Юнит-тест по смыслу должен быстро создать объект, подставить ему зависимость-заглушку и проверить поведение. Если зависимость в конструкторе — это делается так же просто, как собрать табуретку из IKEA (да, я знаю, сравнение опасное, но тут без шестигранника).

Пример теста для constructor injection:

import org.junit.jupiter.api.Test; 
import static org.junit.jupiter.api.Assertions.assertEquals; 

class AuditServiceTest {

    @Test
    void writesMessage() {
        // Заглушка вместо реальной зависимости
        CapturingAuditWriter writer = new CapturingAuditWriter();

        // Зависимость передаём явно — никакого Spring-контекста не нужно
        AuditService service = new AuditService(writer);

        service.audit("created");
        // Проверяем наблюдаемый эффект
        assertEquals("created", writer.lastMessage);
    }
}

А вот сама заглушка — максимально маленькая:

class CapturingAuditWriter implements AuditWriter {
    // Сюда будем “запоминать” последнее сообщение, чтобы тест мог проверить результат
    String lastMessage;

    @Override
    public void write(String message) {
        // Эмулируем запись, но вместо I/O просто сохраняем значение
        this.lastMessage = message;
    }
}

Никакого Spring-контекста. Никакой магии. Чистая Java.

Теперь попробуем сделать то же самое с field injection. Проблема в том, что поле auditWriter приватное и устанавливается контейнером. Значит, в тесте вы либо поднимаете Spring (что для юнит-теста обычно избыточно), либо лезете в рефлексию.

Рефлексия — это когда вы в тесте начинаете вести себя как Spring, но без зарплаты Spring-команды и без гарантии, что всё будет красиво. Пример (и да, это выглядит как наказание):

import org.junit.jupiter.api.Test; 

import java.lang.reflect.Field;

class AuditServiceFieldInjectionTest {

    @Test
    void writesMessage() throws Exception {
        // Объект создаём вручную: зависимость не внедрена
        AuditService service = new AuditService();

        // Дальше — имитация того, что делает контейнер Spring
        Field f = AuditService.class.getDeclaredField("auditWriter");
        f.setAccessible(true); // ломаем инкапсуляцию ради теста
        f.set(service, new CapturingAuditWriter()); // вручную “внедряем” зависимость

        // Теперь не NPE, но тест стал зависеть от имени поля и внутренностей класса
        service.audit("created");
    }
}

Проблема такого теста не в том, что он “сложный”. Проблема в том, что он хрупкий. Переименовали поле — тест сломался. Поменяли модификатор доступа — сломался. Добавили логики в сеттер/инициализацию (которой в field injection обычно нет, но люди изобретательны) — снова сюрпризы.

И вот здесь появляется важный практический вывод для ContextFlow: если сервисный слой у нас constructor-driven, то мы можем тестировать куски бизнес-логики на чистой Java без поднятия контекста. Это не “отдельный курс по тестированию”, это просто способ не превращать каждую проверку в “запусти пол-приложения ради одного метода”.

6. Рефакторинг и fail-fast

В инженерии есть любимый принцип: лучше сломаться рано и понятно, чем поздно и загадочно. Constructor injection помогает этому принципу почти автоматически. Field injection, наоборот, создаёт мягкую почву для “тихих” изменений, которые компилятор не замечает.

Представим, что вы расширили AuditService и добавили ещё одну обязательную зависимость (неважно какую, пусть будет условный форматтер сообщений). В constructor-варианте вы вынуждены обновить конструктор, а значит, вы вынуждены обновить все места, где создаётся объект (включая @Bean-методы и юнит-тесты). Это неприятно… но это и есть fail-fast: компилятор сам покажет вам все точки, которые надо поправить.

В field injection-варианте вы просто добавите ещё одно поле:

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class AuditService {

    // Внешне “ничего не менялось”: конструктор всё ещё пустой
    @Autowired private AuditWriter auditWriter;
    @Autowired private AuditMessageFormatter formatter;

    public void audit(String message) {
        // На этапе компиляции не видно, что formatter обязателен
        auditWriter.write(formatter.format(message));
    }
}

Что произойдёт дальше? Код скомпилируется. Если у вас есть plain Java тесты, которые делали new AuditService(), они тоже скомпилируются (и начнут падать NPE ещё веселее). А если в контексте нет AuditMessageFormatter, то приложение упадёт на старте. Это уже лучше (контейнер хотя бы поймает проблему), но вы всё равно получили ситуацию, где контракт класса не отражён в сигнатуре.

Особенно это заметно, когда вы используете @Bean-методы. С constructor injection зависимость “пробивается” до конфигурации. Пример:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class CoreConfig {

    @Bean
    public AuditService auditService(AuditWriter auditWriter) {
        // Зависимость видна прямо здесь: метод @Bean вынужден явно её принять
        return new AuditService(auditWriter);
    }
}

Если конструктор AuditService изменился — метод auditService() перестанет компилироваться. И это прекрасно: ошибка всплыла там, где вы реально управляете wiring.

С field injection метод @Bean вообще может не замечать изменения: new AuditService() всё ещё компилируется. А вот сервис внутри — уже зависит от нового поля. Итог: wiring “как будто работает”, но на старте контекста вы поймаете UnsatisfiedDependencyException. Это не катастрофа, но это менее “прямой” способ узнавать о поломках.

В учебном проекте ContextFlow мы специально держим код максимально прозрачным. И поэтому хотим, чтобы изменения зависимостей были заметны сразу — в конструкторе и в конфигурации, а не “где-то в рантайме”.

7. Читаемость сервисного слоя в ContextFlow

Когда у вас один сервис и два поля, field injection кажется терпимым. Но сервисный слой — это место, где таких классов становится много, и вы начинаете ценить единый стиль. Если половина сервисов — constructor injection, четверть — field injection “потому что лень”, а ещё пара — вообще с ручными new внутри методов, то проект перестаёт читаться как система.

Вот “плохой” вариант OrderCancellationService (чисто для иллюстрации, не копируйте его как норму):

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class OrderCancellationService {

    // Зависимости спрятаны в полях и заметны только при внимательном просмотре
    @Autowired private OrderStore orderStore;
    @Autowired private AuditService auditService;

    public void cancel(String orderId) {
        auditService.audit("cancel " + orderId);
    }
}

Теперь “хороший” вариант — зависимости объявлены явно и фиксируются сразу:

import org.springframework.stereotype.Service;

@Service
public class OrderCancellationService {

    // Конструктор сразу говорит: без этих двух объектов сервис не существует
    private final OrderStore orderStore;
    private final AuditService auditService;

    public OrderCancellationService(OrderStore orderStore, AuditService auditService) {
        this.orderStore = orderStore;
        this.auditService = auditService;
    }
}

Разница здесь не в количестве строк. Разница в том, что второй класс можно читать как контракт: если вы хотите отменять заказ, вам нужен OrderStore и AuditService. Никаких сюрпризов, никаких “а где он это берёт”.

И ещё один важный момент: когда вы развиваете ContextFlow, вы регулярно будете смотреть на конструкторы сервисов, как на “карту зависимостей” всего приложения. Это почти как pom.xml, только на уровне объектов. Field injection эту карту ломает, потому что зависимости становятся “не там, где вы ожидаете их увидеть”.

8. Типичные ошибки при использовании field injection

Даже если вы уже согласились с тем, что field injection — плохой default, полезно уметь узнавать его “по походке” и понимать, какие ошибки он провоцирует. В реальных проектах вы всё равно встретите этот стиль, особенно в legacy-коде и в старых туториалах, поэтому задача минимум — не пугаться и уметь объяснить, почему он делает код хуже.

Ошибка №1: выбирать field injection только потому, что он короче.
Короткий код приятно писать, но его потом кто-то будет читать, сопровождать и тестировать (и этот кто-то иногда вы сами через три месяца). Field injection экономит пару строк сегодня и создаёт регулярную “ренту” на чтение, тесты и рефакторинг завтра. В сервисном слое лучше держать одну понятную норму: зависимости живут в конструкторе.

Ошибка №2: считать, что если поле private, то “никто не сможет сломать”.
private защищает от прямого доступа из других классов, но не решает ключевую проблему: зависимость не является частью публичного контракта класса. Кроме того, Spring всё равно установит поле через рефлексию, а значит, класс уже зависит от контейнера на более “внутреннем” уровне, чем при constructor injection.

Ошибка №3: смешивать constructor injection и field injection в одном и том же сервисе.
Иногда разработчик делает “частично правильно”: важные зависимости кладёт в конструктор, а ещё парочку “на всякий случай” докидывает через @Autowired поля. В результате класс перестаёт быть честным: у него есть видимый контракт (конструктор) и невидимый довесок (поля). Читатель неизбежно будет ошибаться, думая, что по конструктору он увидел всё.

Ошибка №4: создавать объект через new и надеяться, что он “как в Spring”.
Field injection делает это особенно опасным, потому что new компилируется и выглядит легально. Но объект будет в недособранном состоянии, и ошибка всплывёт позже, обычно в виде NullPointerException. Constructor injection здесь честнее: если зависимость обязательна, вы не сможете забыть её передать.

Ошибка №5: превращать сервисный слой в “аннотационный ковёр”.
Когда @Autowired стоит над каждым вторым полем, класс перестаёт быть классом и начинает выглядеть как «декларация того, что контейнер когда-нибудь принесёт». Это снижает фокус на бизнес-смысл и усиливает ощущение “магии”. На уровне ContextFlow мы специально учимся видеть wiring как обычную инженерную конструкцию, а не как набор заклинаний.