Что не следует добавлять в Coordinator в iOS-архитектуре?

Coordinator должен отвечать только за навигацию и композицию модулей. Нарушение этого принципа приводит к нарушению разделения ответственности (Single Responsibility Principle).

Что не должно быть внутри Coordinator:

• Бизнес-логика: Принятие решений на основе состояния пользователя или данных.
• Состояние приложения: Хранение данных (моделей, флагов, токенов).
• Прямая работа с UI-фреймворками: Жесткая привязка к UINavigationController или UIViewController. Лучше использовать абстракции (протоколы).
• Логика обработки событий: Реакция на действия пользователя внутри экрана — это ответственность ViewModel или Interactor.

Пример нарушения (плохая практика):

// ❌ Coordinator содержит бизнес-логику
class ProfileCoordinator {
    func start() {
        // Решение о том, какой экран показать, основано на данных пользователя
        let isPremium = UserService.shared.currentUser?.isPremium ?? false
        if isPremium {
            showPremiumProfile() // Бизнес-правило внутри координатора
        } else {
            showStandardProfile()
        }
    }
}

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

// ✅ Coordinator занимается только навигацией
class ProfileCoordinator {
    func start(profileType: ProfileType) { // Тип определяется извне
        switch profileType {
        case .premium:
            navigateToPremiumScreen()
        case .standard:
            navigateToStandardScreen()
        }
    }
}