Что такое принцип инверсии зависимостей (DIP)?

Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) — это пятый принцип SOLID. Он декларирует два ключевых правила:

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

Проще говоря: Код, решающий бизнес-задачу, не должен знать, как именно сохраняются данные или отправляются уведомления. Он должен знать только что нужно сделать (интерфейс), а конкретное как (реализация) предоставляется извне.

Проблемный код (нарушение DIP): Высокоуровневый класс OrderService жёстко зависит от конкретного низкоуровневого класса MySQLOrderRepository.

class MySQLOrderRepository {
    public function save(Order $order): void {
        // Деталь: SQL-запрос для вставки в MySQL
    }
}

class OrderService {
    private MySQLOrderRepository $repository;

    public function __construct() {
        // Жёсткая привязка к детали реализации!
        $this->repository = new MySQLOrderRepository();
    }

    public function createOrder(array $items): void {
        $order = new Order($items);
        // Бизнес-логика...
        $this->repository->save($order); // Зависит от MySQL
    }
}
// Сменить базу данных на PostgreSQL без изменения OrderService невозможно.

Решение с применением DIP:

1. Создаём абстракцию (интерфейс) для репозитория.
2. Заставляем высокоуровневый OrderService зависеть от этой абстракции.
3. Реализуем абстракцию в конкретных низкоуровневых классах.
4. Внедряем конкретную реализацию в сервис извне (через конструктор — это Dependency Injection).

// 1. Абстракция, от которой зависят ВСЕ
interface OrderRepositoryInterface {
    public function save(Order $order): void;
}

// 2. Деталь реализации №1 (зависит от абстракции)
class MySQLOrderRepository implements OrderRepositoryInterface {
    public function save(Order $order): void {
        // Реализация для MySQL
        echo "Сохранение заказа в MySQL...n";
    }
}

// 3. Деталь реализации №2 (зависит от абстракции)
class PostgreSQLOrderRepository implements OrderRepositoryInterface {
    public function save(Order $order): void {
        // Реализация для PostgreSQL
        echo "Сохранение заказа в PostgreSQL...n";
    }
}

// 4. Модуль верхнего уровня (зависит от абстракции, а не от деталей)
class OrderService {
    private OrderRepositoryInterface $repository;

    // Зависимость внедряется извне (Dependency Injection)
    public function __construct(OrderRepositoryInterface $repository) {
        $this->repository = $repository;
    }

    public function createOrder(array $items): void {
        $order = new Order($items);
        // Бизнес-логика остаётся неизменной...
        $this->repository->save($order); // Работает с ЛЮБОЙ реализацией интерфейса
    }
}

// Сборка приложения (обычно в контейнере зависимостей)
$mySqlService = new OrderService(new MySQLOrderRepository());
$mySqlService->createOrder([...]); // Сохраняет в MySQL

$postgreSqlService = new OrderService(new PostgreSQLOrderRepository());
$postgreSqlService->createOrder([...]); // Сохраняет в PostgreSQL

Преимущества следования DIP:

• Слабая связанность: Модули изолированы друг от друга.
• Гибкость и расширяемость: Легко добавлять новые реализации (например, CacheOrderRepository, ApiOrderRepository), не трогая бизнес-логику.
• Упрощение тестирования: Для юнит-тестов OrderService можно легко подменить реальный репозиторий мок-объектом (fake), реализующим тот же интерфейс, и тестировать логику в изоляции.
• Устойчивость к изменениям: Изменения в деталях реализации (библиотеке для работы с БД) затрагивают только один конкретный низкоуровневый класс.