Пишем типизированный DI-контейнер для iOS приложения. Часть 1

Привет, читатель! Меня зовут Александр, я техлид iOS в KTS.

В серии статей я поделюсь своим представлением о DI и попробую решить основную проблему библиотечных решений для DI: нам нужно точно знать, что экран соберётся, зависимости подтянутся, а все ошибки мы отловим на этапе компиляции.

Чтобы копнуть вглубь и собрать большинство возможных подводных камней, нужен большой проект со множеством экранов, в идеале разбитый на модули. Предлагаю вам пройти этот путь совместно и написать проект вместе со мной.

Я планирую серию статей, где мы шаг за шагом нарастим массу кодовой базы и рассмотрим такие проблемы как циклические зависимости, жизненные циклы, ленивая загрузка и декомпозиция контейнера.

Если вы готовы, погнали! ?

Для начала давайте составим примерный план того что должно получиться во всей серии. Пока что я детально понимаю, что будет на старте и чуть менее — что будет в конце, имейте в виду.

Содержание статьи №1

• Dependency Injection

• Типы зависимостей

• Проект: напишем контейнер и убедимся, что своё дело он делает хорошо

• Итоги части 1

• Ссылка на часть 2

Что будет в остальных статьях:

• Жизненный цикл зависимостей и как им управлять.

• Декомпозиция контейнера, циклические зависимости.

• Ленивая инициализация.

• Попробуем избавиться от бойлер-плейт кода при создании объектов.

• Модуляризация проекта.

Если по ходу написания статей появятся другие идеи или запросы от комьюнити в комментариях, то можно и переобуться на ходу. Люблю гибкость в таких вопросах, так что не стесняйтесь писать ?

Для начала синхронизируемся на тему понимания принципа Dependency Injection. Начнем с терминологии.

Dependency Injection

?Зависимость для конкретного объекта — это, в моём понимании, любая внешняя сущность, помогающая этому объекту выполнять свои обязанности.

Например, у нас есть два экрана: список чего-либо и детальное отображение: ListViewController и DetailsViewController. Скажем, что ListViewController ходит на бэкенд за данными, и ему в этом помогает некий ItemService. Это зависимость.

Кроме того, чтобы не попасть в ловушку Massive View Controller, мы вынесли бизнес-логику в ListPresenter. Это тоже зависимость. Если мы открываем DetailsViewController, передавая ему id элемента со списка, то id — это тоже зависимость. Итак...

?Dependency Injection — паттерн, который предлагает все зависимости внедрять снаружи, а не инициализировать их внутри самого объекта.

Для этого есть разные способы, но мы сегодня сосредоточимся на одном: внедрение через конструктор в методе init(). Для чего это нужно? Для независимости. Забавная игра слов, верно? Независимость объекта от своих зависимостей: если они приходят снаружи, то мы в любой момент можем их подменить чем-то другим. Например, моками в тестах. Или реализацией с красной кнопкой вместо синей в А/Б тесте.

Типы зависимостей

1️⃣
Данные, которые доступны только в runtime.

Пример: id элемента из списка. Какой бы способ поставления зависимостей мы не выбрали — с DI или без — мы поставляем их снаружи, потому что внутри их нет и появиться они не могут.

2️⃣
То, что мы можем создать в момент, когда инициализируем объект.

Пример: ListPresenter. Скажем, у нас архитектура VIPER и есть ListAssembly, который собирает весь VIPER-модуль. Сущности этого модуля можно создать одновременно и проставить связи между ними, потому что они все должны жить одновременно, и только одновременно.

3️⃣
Зависимости, про которые объект не должен знать много. Ради них и появился паттерн Dependency container.

Пример: ItemService. ListAssembly может заявить, что ей нужен ItemService, но она может не знать, как создавать его самостоятельно. Потому что зависимости ItemService — например HttpClient или Repository для доступа к базе данных — вне зоны ответственности конкретного экрана.

Если мы договорились, то пойдем дальше и познакомимся с проектом.

Проект

Пока у меня всего 2 экрана. Вы уже догадались? List и Details.

Пока непринципиально, что именно за сущности в этом списке, и что за данные на экране детального отображения. Важно, что мы действительно получаем данные с помощью ItemService, который берёт их из базы данных. Бэкенд я пока не подключал. Ну и разумеется, я запрыгиваю в hype train и пишу это все на SwiftUI. Вам может показаться, что в SwiftUI я далеко не спец, но думаю, что к концу серии статей я стану магистром. Посмотрим ☝️?

Архитектура моего проекта — MVVM. С роутерами. Не спрашивайте, я просто хотел в красках показать, что иногда зависимости должны создаваться вместе с созданием объекта и не придумал ничего лучше. Со временем, думаю, выберу что-то более адекватное.

Итак, вот как это сейчас выглядит:

-- MyApp.swift
-- Model
  |-- Item.swift
-- Persistence
  |-- PersistenceController.swift
-- Service
  |-- ItemService.swift
-- Views
  |-- List
    |-- ListAssembly.swift
    |-- ListViewModel.swift
    |-- ListView.swift
    |-- ListRouter.swift
  |-- Details
    |-- DetailsAssembly.swift
    |-- DetailsViewModel.swift
    |-- DetailsView.swift

Быстренько про ответственности сущностей:

• Assembly — сборщик экрана. Её задача — вернуть View, чтобы кто-то снаружи мог её отобразить. Попутно собирает все зависимости для View.

• ViewModel хранит состояние, принимает события от View, обновляет состояние.

• View — что тут скажешь, вьюха.

• Router — немного вырожденная сущность в контексте SwiftUI, но я пока не до конца понимаю, как красиво делать навигацию. В этом проекте он нужен для иллюстрации работы с контейнером. Отвечает за получение View для отображения следующего экрана.

И немного кода:

@MainActor
final class ListAssembly {
	func view() -> ListView {
        let service = ItemService(persistence: PersistenceController.shared)
		let router = ListRouterImpl()
		let viewModel = ListViewModel(service: service, router: router)
		return ListView(viewModel: viewModel)
	}
}

Как видите, DI у меня уже есть: ListView в конструкторе получает свою зависимость, а ListViewModel в конструкторе получает свои. Для контекста — код ListView, ListViewModel и ListRouter:

struct ListView: View {

	@ObservedObject private var viewModel: ListViewModel

	init(viewModel: ListViewModel) {
		self.viewModel = viewModel
	}

    var body: some View {
        NavigationView {
            List {
				ForEach(viewModel.items) { item in
                    NavigationLink {
						viewModel.detailView(by: item.id)
                    } label: {
                        Text(item.text)
                    }
                }
            }
        }
    }

Простой экран с табличкой. Обратите внимание на то, как взаимодействуют View и ViewModel:

@MainActor
final class ListViewModel: ObservableObject {
	struct Item: Identifiable {
		let id: Int
		let text: String
	}

	@Published var items: [Item] = []

	private let service: ListService
	private let router: ListRouter
	
	init(service: ListService, router: ListRouter) {
		self.service = service
		self.router = router
		Task {
			do {
				items = try await service.items().enumerated().map { index, item in
					Item(id: index, text: itemFormatter.string(from: item.timestamp))
				}
			} catch {
				print("No items")
			}
		}
	}

	func detailsView(by id: Int) -> DetailsView? {
		guard let item = items.first(where: { $0.id == id }) else { return nil }
		return router.detailsView(with: item.text)
	}
}

ViewModel умеет делать три вещи: получать данные из ItemService, сохранять их в массив items и возвращать экземпляр DetailsView с помощью обращения к ListRouter:

@MainActor
protocol ListRouter {
	func detailsView(with text: String) -> DetailsView
}

@MainActor
final class ListRouterImpl: ObservableObject {}

extension ListRouterImpl: ListRouter {
	func detailsView(with text: String) -> DetailsView {
		return DetailsAssembly(text: text).view()
	}
}

ListRouter пока создает экземпляр DetailsAssembly самостоятельно.

А вот как открывается самый первый экран:

@main
struct MyApp: App {
	var body: some Scene {
        WindowGroup {
			ListAssembly().view()
        }
    }
}

Главная проблема этого кода — Assembly конкретного экрана создает экземпляр сервиса.

Ведь если сейчас DetailsViewModel понадобится грузить данные для детального отображения с помощью ItemService (что довольно-таки вероятно), то в DetailsAssembly будет та же самая строчка:

let service = ItemService(persistence: PersistenceController.shared)

И это я еще молчу про то, что приходится использовать синглтон PresistenceController, чтобы в обоих экземплярах ItemService был один и тот же экземпляр PresistenceController. А если представить, что мы добавим новый слой абстракции между сервисом и базой — ItemRepository? Теперь в двух местах придется написать вот так:

let repository = ItemRepository(persistence: PersistenceController.shared)
let service = ItemService(repository: repository)

А теперь представим, что у нас не 2 экрана, а 10. А если уровней абстракции больше?

Я предлагаю решать эту проблему с помощью Dependency container.

?Dependency container — сущность, которая будет поставлять внешние зависимости. Контейнер решает, нужно ли создавать новый экземпляр и когда, хранить сильные или слабые ссылки. В нём инкапсулирована вся логика по предоставлению зависимостей.

Теперь Assembly будут получать на вход данные, которые появляются только в runtime (зависимости первого типа из начала статьи), создавать экземпляры View, ViewModel и Router (зависимости второго типа) и запрашивать у контейнера сущности, про создание которых экран знать не должен, к примеру сервисы (зависимости третьего типа).

Поскольку контейнер у нас будет пока один — AppContainer — то для него зависимостей третьего типа не будет. Он будет знать обо всех сущностях. Соответственно, контейнер будет получать на вход зависимости первого типа, а остальные — создавать. И первой его задачей будет создать ListAssembly, чтобы вынести ее создание из MyApp.swift:

@MainActor
final class AppContainer: ObservableObject {
	func makeListAssembly() -> ListAssembly {
		ListAssembly()
	}
}

Довольно простой код. Теперь нужно научить ListAssembly запрашивать ItemService у AppContainer.

Будем идти в обратном направлении: сначала запрашивать зависимости, а потом реализовывать их поставку, чтобы убедиться, что компилятор помогает нам на каждом этапе.

И ещё важный момент. Я не хочу, чтобы ListAssembly мог запросить у AppContainer что-то лишнее, поэтому мы спрячем его за протокол.

protocol ListContainer {
	func makeItemService() -> ItemService
}

@MainActor
final class ListAssembly {
	private let container: ListContainer

	init(container: ListContainer) {
		self.container = container
	}

	func view() -> ListView {
		let service = container.makeListService()
		let router = ListRouterImpl()
		let viewModel = ListViewModel(service: service, router: router)
		return ListView(viewModel: viewModel)
	}
}

Красота. Ничего не билдится, компилятор говорит, что мы не передали в конструктор ListAssembly новую зависимость — ListContainer. Исправляем:

func makeListAssembly() -> ListAssembly {
	ListAssembly(container: self)
}

Теперь компилятор ругается, что AppContainer не соответствует протоколу ListContainer. Исправляем:

extension AppContainer: ListContainer {
	func makeItemService() -> ItemService {
		ItemServiceImpl(persistence: PersistenceController.shared)
	}
}

Но стоп! Теперь у нас есть контейнер и не нужно использовать синглтон PersistenceController. Пусть экземпляр PersistenceController тоже хранится в AppContainer:

@MainActor
final class AppContainer: ObservableObject {
    private let persistenceController = PersistenceController()

    func makeListAssembly() -> ListAssembly {
		ListAssembly()
	}
}

extension AppContainer: ListContainer {
	func makeItemService() -> ItemService {
		ItemServiceImpl(persistence: persistenceController)
	}
}

Красотища! Все работает. Теперь нужно избавиться от явного создания DetailsAssembly в роутере списка:

@MainActor
final class ListRouterImpl: ObservableObject {
    private let container: ListContainer

	init(container: ListContainer) {
		self.container = container
	}
}

extension ListRouterImpl: ListRouter {
	func detailsView(with text: String) -> DetailsView {
		return container.makeDetailsAssembly(text: text).view()
	}
}

Снова ругается компилятор. Чиним:

protocol ListContainer {
	func makeItemService() -> ItemService
    func makeDetailsAssembly(text: String) -> DetailsAssembly
}

@MainActor
final class ListAssembly {
	private let container: ListContainer

	init(container: ListContainer) {
		self.container = container
	}

	func view() -> ListView {
		let service = container.makeListService()
		let router = ListRouterImpl(container: container)
		let viewModel = ListViewModel(service: service, router: router)
		return ListView(viewModel: viewModel)
	}
}

extension AppContainer: ListContainer {
	func makeItemService() -> ItemService {
		ItemServiceImpl(persistence: persistenceController)
	}

	func makeDetailsAssembly(text: String) -> DetailsAssembly {
		DetailsAssembly(container: self, text: text)
	}
}

Пока что DetailsAssembly зависит от ListContainer, но я поправлю это в будущих статьях этой серии, когда будем рассматривать декомпозицию контейнера. Главное, что мы получили — возможность модифицировать способ создания экземпляра ItemService всего в одном месте, хотя используется он во многих.

Итоги части 1

• Мы установили общий контекст для статей: что такое зависимости, какие они бывают и что такое Dependency Injection. Эти определения — моя интерпретация для общего понимания будущих материалов

• На примере увидели опасность создания зависимостей третьего типа прямо перед созданием объекта, от них зависящего

• Воспользовались паттерном Dependency container, который спрятали за протокол и научились запрашивать зависимости третьего типа

В следующей статье я продолжу развивать контейнер. Посмотрим, чему его нужно будет научить на проекте побольше.

Stay tuned! ??

UPD Читайте вторую часть статьи — Жизненные циклы

Другие наши статьи по iOS-разработке:

• Начало работы с Dynamic Island и Live Activities в iOS 16.1

• Подключение OAuth в iOS за полчаса

• KMM глазами iOS-разработчика