В чем разница между Dependency Injection (DI) и Dependency Inversion Principle (DIP)?

Question

В чем разница между Dependency Injection (DI) и Dependency Inversion Principle (DIP)?

Тип вопроса: Архитектура Вероятность: 10% Категория: Java Разработчик

Ответ

Dependency Inversion Principle (DIP) — это принцип проектирования (буква "D" в SOLID). Он состоит из двух правил:

Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракций (интерфейсов).
Абстракции не должны зависеть от деталей. Детали (реализации) должны зависеть от абстракций.

Dependency Injection (DI) — это паттерн/техника реализации DIP, при котором зависимости объекта предоставляются ему извне ("внедряются"), а не создаются внутри класса.

Связь: DI — это практический способ соблюсти DIP.

Пример DIP + DI:

// Абстракция (интерфейс) - от нее зависят оба уровня
interface NotificationService {
    void send(String message);
}

// Деталь (нижний уровень) зависит от абстракции
class EmailService implements NotificationService {
    public void send(String message) { /* отправка email */ }
}

// Модуль верхнего уровня зависит от абстракции, а не от EmailService
class UserController {
    private final NotificationService service; // Зависимость от абстракции

    // Dependency Injection через конструктор
    public UserController(NotificationService service) {
        this.service = service; // Конкретная реализация внедряется извне
    }

    public void notifyUser() {
        service.send("Hello!");
    }
}

Итог: DIP — это "что" (цель проектирования), DI — это "как" (способ достижения).

Ответ 18+ 🔞

А, слушай, смотри, сейчас я тебе такую хуйню объясню про DIP и DI, что у тебя в голове всё встанет на свои места, как пьяный в автобусе на последней остановке.

Вот есть у нас этот ваш SOLID, буква «D» в нём — это и есть Dependency Inversion Principle, или, по-нашему, Принцип Инверсии Зависимостей. Звучит заумно, а суть проще пареной репы, если не перегибать с абстракциями, конечно.

Представь себе, блядь, двух мужиков: один — начальник цеха (модуль верхнего уровня), другой — токарь Вася (модуль нижнего уровня). Так вот, по старой, кривой архитектуре, начальник привязан к Васе намертво. «Вася, деталь!» — и всё. А если Вася в запой ушёл? Пиздец производству. Начальник в жопе.

DIP приходит и говорит: «Да пошли вы нахуй с этой жесткой связкой!». Правило первое: пусть начальник зависит не от конкретного Васи, а от абстракции — от «токаря» вообще. И сам Вася тоже должен от этой абстракции зависеть. То есть оба смотрят на одну и ту же бумажку с требованиями «что должен уметь токарь», а не друг на друга.

Правило второе: эта самая бумажка-абстракция не должна говорить «крути ручку синей краской». Нет, блядь! Она говорит «делай деталь по чертежу». А уже детали реализации — будет ли Вася крутить ручку, или Петя будет жмакать кнопку на ЧПУ — это их, реализаторов, проблемы. Детали пляшут от абстракции, а не наоборот.

А теперь, внимание, ебушки-воробушки, Dependency Injection — это как раз тот самый механизм, который впихивает нужного тебе Васю (или Петю) начальнику в руки. Это не принцип, а техника, паттерн, способ сделать так, чтобы начальник не сам искал Васю по цеху, а ему его привели и сказали: «Вот тебе токарь, работай».

Связь-то какая? DI — это практический способ, хуй с горы, чтобы DIP в жизни воплотить. Без DI соблюсти DIP — это как пытаться собрать мебель из IKEA без шестигранника — вроде и понятно, что надо, но нихуя не получается.

Смотри на примере, тут всё станет ясно, как божий день. Вот у нас есть некая абстракция — что должен уметь сервис уведомлений.

// Вот она, бумажка-абстракция. И начальник, и работники на неё смотрят.
interface NotificationService {
    void send(String message);
}

А вот деталь, нижний уровень — Вася, который шлёт письма.

// Вася-имейлщик. Он зависит от абстракции, то есть обязуется её выполнять.
class EmailService implements NotificationService {
    public void send(String message) { /* тут он пашет, отправляет email */ }
}

И вот наш модуль верхнего уровня — начальник, который хочет уведомлять пользователей.

class UserController {
    // Смотри, какая красота! Он про Васю ничего не знает.
    // Он заточен на абстракцию — «сервис уведомлений».
    private final NotificationService service;

    // А ВОТ И ОН — DEPENDENCY INJECTION, МАТЬ ЕГО!
    // Кто-то снаружи (например, фабрика или фреймворк) приносит нам
    // готового работника (Ваську, Петьку, СМС-ку) и всовывает его сюда.
    public UserController(NotificationService service) {
        this.service = service; // Внедрили, блядь, зависимость!
    }

    public void notifyUser() {
        // И начальнику похуй, кто там работает. Есть бумажка — есть работа.
        service.send("Hello!");
    }
}

Итог, блядь, простой, как три копейки:

DIP (Принцип) — это ЧТО мы хотим: развязать модули, заставить их смотреть на абстракции. Это цель, философия.
DI (Внедрение зависимостей) — это КАК мы это делаем: не даём объекту самому лезть за своими зависимостями, а впихиваем их ему снаружи. Это инструмент, отвёртка.

Вот и вся магия. Сначала придумали, как должно быть правильно (DIP), а потом придумали удобный способ это делать (DI). А то без DI этот принцип — просто пустые слова, как обещание «завтра брошу пить».