В чем разница между принципом инверсией зависимостей и принципом инъекции зависимостей?

DIP vs DI: Инверсия зависимостей vs Инъекция зависимостей

Эти два принципа часто путают из-за похожих названий, но это совершенно разные концепции. DIP (Dependency Inversion Principle) — это принцип проектирования, а DI (Dependency Injection) — это техника реализации.

Инверсия зависимостей (DIP — Dependency Inversion Principle)

Это принцип из SOLID, который говорит:

Высокоуровневые модули НЕ должны зависеть от низкоуровневых модулей. Оба должны зависеть от абстракций.

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Плохо (нарушение DIP):

// UserService зависит НАПРЯМУЮ от конкретного класса DatabaseRepository
public class UserService {
    private DatabaseRepository repository = new DatabaseRepository();  // Жёсткая зависимость!
    
    public User getUser(Long id) {
        return repository.findById(id);
    }
}

// Если захотим поменять на FileRepository, придётся менять UserService!
// Высокоуровневый модуль (UserService) зависит от низкоуровневого (DatabaseRepository)

Хорошо (применён DIP):

// 1. Создаём абстракцию (интерфейс)
public interface UserRepository {
    User findById(Long id);
}

// 2. Реализации зависят от интерфейса
public class DatabaseRepository implements UserRepository {
    @Override
    public User findById(Long id) {
        // Реализация через БД
        return database.query("SELECT * FROM users WHERE id = ?", id);
    }
}

public class FileRepository implements UserRepository {
    @Override
    public User findById(Long id) {
        // Реализация через файлы
        return readFromFile(id);
    }
}

// 3. UserService зависит от ИНТЕРФЕЙСА, не от конкретной реализации
public class UserService {
    private UserRepository repository;  // Зависит от интерфейса!
    
    public UserService(UserRepository repository) {
        this.repository = repository;  // Принимает любую реализацию
    }
    
    public User getUser(Long id) {
        return repository.findById(id);
    }
}

// Теперь можем легко переключаться между реализациями
UserService service1 = new UserService(new DatabaseRepository());
UserService service2 = new UserService(new FileRepository());

DIP это ПРИНЦИП — что делать, но не как это делать.

Инъекция зависимостей (DI — Dependency Injection)

Это техника реализации, которая помогает соблюдать DIP. DI — это способ предоставить объекту его зависимости извне, вместо того, чтобы объект создавал их сам.

Есть три типа DI:

1. Инъекция через конструктор (Constructor Injection) — ЛУЧШИЙ подход

public class UserService {
    private UserRepository repository;
    
    // Зависимость передаётся через конструктор
    public UserService(UserRepository repository) {
        this.repository = repository;
    }
    
    public User getUser(Long id) {
        return repository.findById(id);
    }
}

// Использование
UserService service = new UserService(new DatabaseRepository());

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

• Зависимость обязательна (видна в сигнатуре конструктора)
• Нельзя создать объект без зависимости
• Легко тестировать (передаём mock)
• Объект неизменяемый (immutable)

2. Инъекция через сеттер (Setter Injection)

public class UserService {
    private UserRepository repository;
    
    // Зависимость устанавливается позже через сеттер
    public void setRepository(UserRepository repository) {
        this.repository = repository;
    }
    
    public User getUser(Long id) {
        return repository.findById(id);
    }
}

// Использование
UserService service = new UserService();
service.setRepository(new DatabaseRepository());

Недостатки:

• Объект может быть создан без зависимости (потенциальные ошибки)
• Сложнее отследить обязательные зависимости

3. Инъекция через интерфейс (Interface Injection)

public interface RepositoryInjector {
    void injectRepository(UserRepository repository);
}

public class UserService implements RepositoryInjector {
    private UserRepository repository;
    
    @Override
    public void injectRepository(UserRepository repository) {
        this.repository = repository;
    }
}

// Использование
UserService service = new UserService();
RepositoryInjector injector = service;
injector.injectRepository(new DatabaseRepository());

DI это ТЕХНИКА — как это реализовать.

Spring Framework и DI

В Spring DI реализуется автоматически через контейнер:

// Spring автоматически создаёт объекты и подставляет зависимости
@Service
public class UserService {
    private final UserRepository repository;
    
    // Spring автоматически вызовет конструктор с бином UserRepository
    @Autowired
    public UserService(UserRepository repository) {
        this.repository = repository;
    }
    
    public User getUser(Long id) {
        return repository.findById(id);
    }
}

@Repository
public class DatabaseRepository implements UserRepository {
    // Spring создаст бин и подставит его в UserService
    @Override
    public User findById(Long id) {
        // ...
    }
}

Сравнение: DIP vs DI

Практический пример

// Применяем DIP (через интерфейсы)
public interface PaymentGateway {
    void processPayment(BigDecimal amount);
}

public class StripePaymentGateway implements PaymentGateway {
    @Override
    public void processPayment(BigDecimal amount) {
        // Интеграция со Stripe
    }
}

public class PayPalPaymentGateway implements PaymentGateway {
    @Override
    public void processPayment(BigDecimal amount) {
        // Интеграция с PayPal
    }
}

// Применяем DI (через конструктор)
public class OrderService {
    private final PaymentGateway paymentGateway;
    
    // Зависимость инъектируется через конструктор
    public OrderService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }
    
    public void checkoutOrder(Order order) {
        paymentGateway.processPayment(order.getTotal());
    }
}

// Результат: слабая связанность + управляемые зависимости
OrderService service1 = new OrderService(new StripePaymentGateway());
OrderService service2 = new OrderService(new PayPalPaymentGateway());
OrderService service3 = new OrderService(new MockPaymentGateway()); // Для тестов

Итог

• DIP — принцип: "Зависимости должны идти на интерфейсы, не на реализации"
• DI — техника: "Передавай зависимости извне, не создавай их внутри"
• DIP без DI — возможно, но сложно управлять зависимостями вручную
• DI без DIP — даёт управление, но не гарантирует гибкость архитектуры
• DIP + DI вместе — идеальная комбинация для чистой архитектуры