Какие знаешь способы работы с зависимостями?

Способы управления зависимостями в iOS-разработке

Управление зависимостями — ключевой аспект создания поддерживаемых, тестируемых и масштабируемых приложений. Вот основные подходы и инструменты, которые я применяю в iOS-разработке.

1. Внедрение зависимостей (Dependency Injection)

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

Основные виды DI:

• Инициализатор (Constructor Injection) — зависимости передаются через инициализатор
• Свойство (Property Injection) — зависимости устанавливаются через свойства объекта
• Метод (Method Injection) — зависимости передаются как параметры метода

// Constructor Injection пример
protocol NetworkServiceProtocol {
    func fetchData() -> Data
}

class DataManager {
    private let networkService: NetworkServiceProtocol
    
    init(networkService: NetworkServiceProtocol) {
        self.networkService = networkService
    }
    
    func loadData() {
        let data = networkService.fetchData()
        // обработка данных
    }
}

// Использование
let networkService = NetworkService()
let dataManager = DataManager(networkService: networkService)

2. Сервис-локаторы (Service Locator)

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

class ServiceLocator {
    static let shared = ServiceLocator()
    private var services: [String: Any] = [:]
    
    func register<T>(service: T, for type: T.Type) {
        services[String(describing: type)] = service
    }
    
    func resolve<T>() -> T? {
        return services[String(describing: T.self)] as? T
    }
}

// Регистрация
ServiceLocator.shared.register(service: NetworkService(), for: NetworkServiceProtocol.self)

// Разрешение
let networkService = ServiceLocator.shared.resolve(NetworkServiceProtocol.self)

3. Фабрики и абстрактные фабрики

Фабричный метод и Абстрактная фабрика — паттерны для создания объектов без указания конкретных классов.

protocol ViewModelFactoryProtocol {
    func createProductViewModel() -> ProductViewModelProtocol
    func createCatalogViewModel() -> CatalogViewModelProtocol
}

class DefaultViewModelFactory: ViewModelFactoryProtocol {
    private let dependencies: DependenciesContainer
    
    init(dependencies: DependenciesContainer) {
        self.dependencies = dependencies
    }
    
    func createProductViewModel() -> ProductViewModelProtocol {
        return ProductViewModel(
            productService: dependencies.productService,
            analyticsService: dependencies.analyticsService
        )
    }
}

4. Современные DI-фреймворки

Для сложных проектов я использую специализированные фреймворки:

Swinject

Популярный легковесный DI-контейнер:

let container = Container()
container.register(NetworkServiceProtocol.self) { _ in 
    NetworkService()
}
container.register(DataManager.self) { resolver in
    DataManager(networkService: resolver.resolve(NetworkServiceProtocol.self)!)
}

let dataManager = container.resolve(DataManager.self)

Needle

Фреймворк от Uber с проверкой зависимостей на этапе компиляции:

// Needle генерирует код на основе описания графа зависимостей

5. Композиция корневых объектов

Composition Root — паттерн, при котором все зависимости разрешаются в одном месте (обычно в AppDelegate или корневом координаторе).

class AppDependencyContainer {
    lazy var networkService: NetworkServiceProtocol = NetworkService()
    lazy var dataManager: DataManagerProtocol = DataManager(
        networkService: networkService
    )
    lazy var mainCoordinator: MainCoordinator = {
        MainCoordinator(dataManager: dataManager)
    }()
}

// В AppDelegate
let container = AppDependencyContainer()
window.rootViewController = container.mainCoordinator.start()

6. Управление зависимостями в SwiftUI

В SwiftUI используется @EnvironmentObject и @Environment:

class AppState: ObservableObject {
    @Published var userSession: UserSession?
}

struct ContentView: View {
    @EnvironmentObject var appState: AppState
    @Environment(\.horizontalSizeClass) var sizeClass
    
    var body: some View {
        if appState.userSession != nil {
            MainView()
        } else {
            LoginView()
        }
    }
}

// Инициализация
ContentView().environmentObject(AppState())

7. Модульность и SPM

Swift Package Manager позволяет декомпозировать проект на модули с чёткими границами зависимостей:

// Package.swift
dependencies: [
    .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.4.0"),
    .package(path: "../InternalNetworkingModule")
]

Критерии выбора подхода

При выборе способа работы с зависимостями я учитываю:

1. Сложность проекта — для маленьких проектов подходит ручное внедрение, для больших — DI-фреймворки
2. Команда и expertise — насколько команда знакома с выбранным подходом
3. Тестируемость — насколько легко будет писать unit-тесты
4. Время компиляции — некоторые фреймворки (Needle) могут увеличить время компиляции
5. Безопасность типов — проверка зависимостей на этапе компиляции vs runtime

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

• Инверсия зависимостей — зависьте от абстракций, а не от реализаций
• Один уровень абстракции — не смешивайте высокоуровневые и низкоуровневые зависимости
• Явные зависимости — избегайте скрытых зависимостей через синглтоны или глобальные переменные
• Циклические зависимости — проектируйте граф зависимостей без циклов
• Лайфтайм объектов — чётко определяйте время жизни каждого объекта

В моей практике я чаще всего комбинирую ручное внедрение зависимостей через инициализаторы с использованием протоколов для абстракций. Для сложных проектов добавляю Swinject или другой DI-контейнер. Ключевой принцип — сохранять код тестируемым и гибким к изменениям, что достигается правильным управлением зависимостями.