Внедрение зависимостей (Dependency Injection) в Swift: полное руководство для начинающих

Введение: Почему ваш код нуждается в Dependency Injection?

Каждый разработчик iOS сталкивается с ситуацией, когда класс становится "толстым" и жёстко привязанным к конкретным реализациям. Вы меняете один класс, а переписывать приходится десятки других. Знакомо? Это классическая проблема сильной связанности (tight coupling).

Dependency Injection (DI) — это паттерн проектирования, который решает эту проблему. Вместо того чтобы объект сам создавал свои зависимости, они "внедряются" извне. Это делает код гибким, тестируемым и соответствующим принципам SOLID (в частности, принципу инверсии зависимостей).

В этой статье мы разберём, что такое DI в Swift, какие существуют способы его реализации, и как он упрощает жизнь iOS/macOS разработчику. Мы будем использовать простые примеры, понятные даже новичку.

Что такое Dependency Injection? Простой пример

Представьте, что вы печёте пиццу. Вариант без DI: вы сами выращиваете пшеницу, делаете муку, доите корову для сыра. Это жёсткая связь. Вариант с DI: вы просто заказываете ингредиенты (зависимости) у поставщика. Вы не знаете, как сделана мука — вам важен только результат.

В программировании то же самое. Допустим, у нас есть класс OrderService, который отправляет заказы по email:

// ❌ Без DI — жёсткая связь
class OrderService {
    let mailer = Mailer() // Создаёт зависимость сам

    func process(order: Order) {
        mailer.send(email: "Новый заказ: \(order.id)")
    }
}

Проблема: мы не можем подменить Mailer на тестовую версию. Класс OrderService "знает" слишком много.

// ✅ С DI — зависимость внедряется
class OrderService {
    let mailer: MailerProtocol // Зависим от абстракции, а не конкретики

    init(mailer: MailerProtocol) { // Внедрение через инициализатор
        self.mailer = mailer
    }

    func process(order: Order) {
        mailer.send(email: "Новый заказ: \(order.id)")
    }
}

Теперь мы можем передать любой объект, соответствующий протоколу MailerProtocol — реальный почтовик или "заглушку" для тестов.

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

Существует три популярных способа передать зависимость в класс. Рассмотрим каждый.

1. Constructor Injection (через инициализатор)

Самый распространённый и предпочтительный способ. Зависимость передаётся при создании объекта. Это гарантирует, что объект всегда находится в валидном состоянии.

protocol NetworkServiceProtocol {
    func fetchData() -> String
}

class RealNetworkService: NetworkServiceProtocol {
    func fetchData() -> String { return "Реальные данные с сервера" }
}

class MockNetworkService: NetworkServiceProtocol {
    func fetchData() -> String { return "Тестовые данные" }
}

class DataManager {
    private let network: NetworkServiceProtocol

    // Зависимость передаётся через init
    init(network: NetworkServiceProtocol) {
        self.network = network
    }

    func load() -> String {
        return network.fetchData()
    }
}

// Использование
let realManager = DataManager(network: RealNetworkService())
let mockManager = DataManager(network: MockNetworkService())

Плюсы: Явно видно, какие зависимости нужны. Объект сразу готов к работе. Минусы: Если зависимостей много, инициализатор становится громоздким.

2. Property Injection (через свойство)

Зависимость устанавливается после создания объекта. Часто используется, когда зависимость опциональна или её трудно получить в момент инициализации.

class UserViewModel {
    var apiService: NetworkServiceProtocol? // Опциональная зависимость

    func loadUser() {
        apiService?.fetchData()
    }
}

// Использование
let viewModel = UserViewModel()
viewModel.apiService = RealNetworkService() // Устанавливаем позже
viewModel.loadUser()

Плюсы: Гибкость, можно менять зависимости "на лету". Минусы: Объект может быть в невалидном состоянии, если забыть установить зависимость. Сложнее тестировать.

3. Method Injection (через метод)

Зависимость передаётся только в момент вызова конкретного метода. Идеально, когда зависимость нужна для одной операции.

class PaymentProcessor {
    func processPayment(amount: Double, using gateway: PaymentGatewayProtocol) {
        gateway.charge(amount: amount)
    }
}

protocol PaymentGatewayProtocol {
    func charge(amount: Double)
}

// Использование
let processor = PaymentProcessor()
processor.processPayment(amount: 100.0, using: StripeGateway())
processor.processPayment(amount: 50.0, using: PayPalGateway())

Плюсы: Минимальная связанность. Минусы: Неудобно, если метод вызывается часто или зависимость нужна в нескольких методах.

Dependency Injection и протоколы: основа гибкости

Ключевой элемент DI в Swift — это протоколы. Они позволяют создавать абстракции и подменять реализации без изменения кода клиента. Это называется принцип инверсии зависимостей (Dependency Inversion Principle) — "зависите от абстракций, а не от конкретных реализаций".

Рассмотрим реальный пример с аналитикой в приложении:

// 1. Определяем протокол (абстракцию)
protocol AnalyticsService {
    func logEvent(_ name: String, parameters: [String: Any])
}

// 2. Реальная реализация (например, Firebase)
class FirebaseAnalytics: AnalyticsService {
    func logEvent(_ name: String, parameters: [String: Any]) {
        print("Firebase: \(name) - \(parameters)")
        // Реальный код отправки в Firebase
    }
}

// 3. Тестовая реализация (заглушка)
class MockAnalytics: AnalyticsService {
    var lastEvent: String?
    func logEvent(_ name: String, parameters: [String: Any]) {
        lastEvent = name
        print("Mock: событие записано в лог")
    }
}

// 4. Класс, использующий аналитику
class ProfileViewController {
    let analytics: AnalyticsService

    init(analytics: AnalyticsService) {
        self.analytics = analytics
    }

    func viewDidAppear() {
        analytics.logEvent("profile_opened", parameters: ["user_id": "123"])
    }
}

// 5. Создание в разных сценариях
// В production:
let vc = ProfileViewController(analytics: FirebaseAnalytics())
// В тестах:
let testVC =