Какой бы выбрал способ внедрения зависимости?

Выбор способа внедрения зависимостей (Dependency Injection)

Этот вопрос проверяет не просто знание DI паттернов, но понимание компромиссов между различными подходами. За 10+ лет я использовал все три способа и имею твердое мнение по этому поводу.

Три способа внедрения зависимостей

1. Constructor Injection (Инъекция через конструктор)

public class OrderService {
    private final PaymentService paymentService;
    private final NotificationService notificationService;
    private final OrderRepository orderRepository;
    
    // Constructor injection
    public OrderService(
            PaymentService paymentService,
            NotificationService notificationService,
            OrderRepository orderRepository) {
        this.paymentService = paymentService;
        this.notificationService = notificationService;
        this.orderRepository = orderRepository;
    }
    
    public void processOrder(Order order) {
        paymentService.charge(order);
        notificationService.send(order);
        orderRepository.save(order);
    }
}

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

• Зависимости очевидны сразу при создании объекта
• Все зависимости final, поэтому immutable
• Легко тестировать (передаешь mock'и в конструктор)
• Spring автоматически обнаруживает циклические зависимости при инициализации
• Работает без аннотаций (pure Java)

Недостатки:

• Если 10+ зависимостей, конструктор становится огромным (signal что класс делает слишком много)

2. Setter Injection (Инъекция через setter'ы)

public class OrderService {
    private PaymentService paymentService;
    private NotificationService notificationService;
    
    @Autowired
    public void setPaymentService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
    
    @Autowired
    public void setNotificationService(NotificationService notificationService) {
        this.notificationService = notificationService;
    }
    
    public void processOrder(Order order) {
        paymentService.charge(order);
        notificationService.send(order);
    }
}

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

• Гибкость: можно создать объект без всех зависимостей
• Если много зависимостей, конструктор небольшой

Недостатки:

• Объект может быть в invalid состоянии (зависимость не установлена)
• Сложнее тестировать (нужно вызывать setter'ы после создания)
• Зависимости не очевидны сразу
• На production может упасть, если забыл один setter
• NullPointerException ловушка

3. Field Injection (Инъекция в поля)

public class OrderService {
    @Autowired
    private PaymentService paymentService;
    
    @Autowired
    private NotificationService notificationService;
    
    public void processOrder(Order order) {
        paymentService.charge(order);
        notificationService.send(order);
    }
}

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

• Компактно, выглядит просто
• Мало кода

Недостатки:

• ОЧЕНЬ сложно тестировать (нужно использовать reflection для установки полей)
• Скрывает зависимости, не очевидно при чтении класса
• Нельзя использовать final
• Зависит только от Spring, не работает без DI контейнера
• Spring явно рекомендует НЕ использовать этот подход

Мой выбор и почему

Я ВСЕГДА выбираю Constructor Injection. Вот почему:

Причина 1: Явность

// Constructor Injection - сразу видно все зависимости
public OrderService(
        PaymentService paymentService,
        NotificationService notificationService,
        OrderRepository orderRepository) { }

// Если конструктор очень большой (10+ параметров),
// это СИГНАЛ что класс нарушает Single Responsibility Principle
// Нужно разбить класс на несколько

Причина 2: Тестируемость

// Юнит тест без Spring контейнера!
public void testOrderProcessing() {
    PaymentService paymentMock = mock(PaymentService.class);
    NotificationService notificationMock = mock(NotificationService.class);
    OrderRepository repoMock = mock(OrderRepository.class);
    
    OrderService orderService = new OrderService(
        paymentMock,
        notificationMock,
        repoMock
    );
    
    // Быстро, без Spring контекста
    orderService.processOrder(order);
    verify(paymentMock).charge(order);
}

Причина 3: Immutability

public class OrderService {
    private final PaymentService paymentService;  // final!
    private final OrderRepository orderRepository;  // final!
    
    public OrderService(...) { ... }
}

// Зависимости не могут быть изменены после создания
// Thread-safe по умолчанию

Причина 4: Обнаружение проблем при инициализации

// Если циклическая зависимость:
// A -> B -> A

// Spring обнаружит при старте приложения:
// BeanCurrentlyInCreationException при Constructor Injection

// Field Injection: обнаружит позже или не обнаружит вообще

Spring и Constructor Injection

Since Spring 4.3, Spring автоматически инъектирует зависимости в конструктор, если он один:

// Не нужна аннотация @Autowired!
@Service
public class OrderService {
    private final PaymentService paymentService;
    private final OrderRepository orderRepository;
    
    // Spring автоматически найдет и инъектит
    public OrderService(PaymentService paymentService, 
                        OrderRepository orderRepository) {
        this.paymentService = paymentService;
        this.orderRepository = orderRepository;
    }
}

Когда может быть исключение?

Оптиональные зависимости:

public class ReportService {
    private final ReportRepository reportRepository;
    private final Optional<EmailService> emailService;
    
    public ReportService(
            ReportRepository reportRepository,
            Optional<EmailService> emailService) {
        this.reportRepository = reportRepository;
        this.emailService = emailService;  // Может быть не сконфигурирована
    }
    
    public void generateReport(Report report) {
        reportRepository.save(report);
        emailService.ifPresent(service -> service.sendReport(report));
    }
}

Anti-pattern'ы которых нужно избегать

Плохо: Service Locator паттерн

// АНТИПАТТЕРН - не делай так!
public class OrderService {
    private final ServiceLocator locator;
    
    public void processOrder(Order order) {
        PaymentService payment = locator.getService(PaymentService.class);
        // Скрывает зависимости, сложно тестировать
    }
}

Плохо: Static factory методы

// АНТИПАТТЕРН
public class OrderService {
    public void processOrder(Order order) {
        PaymentService payment = PaymentServiceFactory.getInstance();
        // Нельзя mock'ить в тестах
    }
}

Лучшие практики

1. Используй Constructor Injection по умолчанию
2. Если конструктор слишком большой (5+ параметров), разбей класс на несколько
3. Используй Lombok для сокращения кода

@Service
@RequiredArgsConstructor  // Генерирует конструктор автоматически
public class OrderService {
    private final PaymentService paymentService;
    private final OrderRepository orderRepository;
    private final NotificationService notificationService;
}

1. Делай зависимости final — это предотвращает ошибки
2. Избегай циклических зависимостей — это сигнал проблемы в дизайне

Итог

Выбор способа DI не просто вопрос предпочтения — это вопрос архитектуры и качества кода. Constructor Injection — это золотой стандарт потому что он:

• Делает зависимости явными
• Обеспечивает тестируемость
• Гарантирует immutability
• Обнаруживает проблемы рано

Это мой выбор в 99% случаев, и я рекомендую его в любом Java проекте.