Что такое Clean Swift (VIP-цикл)?

А, Clean Swift, блядь! VIP, VIPER... Ну, это ж как в том анекдоте про Герасима, который немой, но зато силачище, блядь. Только тут не Муму топят, а твой мозг пытаются утопить в овердохуище файлов и протоколов.

Смотри, сука, в чём соль. Представь, что ты — барин, а твой код — крепостные. В обычной жизни все в одной избе живут, друг на друге сидят, и кто серит на крыше — непонятно. А тут приходит Тургенев, ёпта, и говорит: «Нет, блядь, так не пойдёт. Разделяй и властвуй, нахуй!»

Вот и родился этот VIP-цикл, пиздопроебибна архитектура. Слушай сюда, как оно работает:

View (ViewController) — это такой холуй, который только умеет глазами водить и на кнопки показывать. «Барин, пользователь ткнул!» — и всё. Сам нихуя не решает. Всю логику — следующему.

Interactor — а вот это уже мозги, блядь. Настоящий управляющий. Получает от холуя сообщение, что ткнули, и начинает думать: «Так, блядь, а что по этому поводу говорит бизнес?» Работает с какими-то своими, чистыми, сущностями (Entities). Но сам в сарай за дровами не ходит — для этого есть Worker.

Worker (Service) — это тот самый Герасим, здоровый и немой. Ему говорят: «Принеси дров!» — он идёт в лес, блядь, или в интернет, или в базу данных, и тащит. Никаких лишних вопросов. Принёс — отдал управляющему.

Presenter — а это, сука, придворный поэт. Управляющий принёс ему сырые дрова (данные), а поэт должен из этого сложить красивую речь, чтобы холую-View было что на тарелке барину подать. «Не просто „дрова“, а „ароматные поленья ядрёного дуба“!» Форматирует всё в ViewModel.

Router (Wireframe) — ну а этот, блядь, как швейцар в хорошем отеле. Его задача — когда барин говорит «Хочу в соседний зал!», он должен дверь открыть и правильно проводить. Навигация, короче.

И вот они все, сука, по кругу бегают, как белка в колесе. View тыкнули -> Interactor подумал -> Worker сходил -> Presenter приукрасил -> View показал. И так до скончания века.

// 1. Холуй (View) увидел, что барин проснулся
override func viewDidLoad() {
    super.viewDidLoad()
    // И сразу бежит к управляющему докладывать
    interactor?.fetchList(request: List.Fetch.Request())
}

// 2. Управляющий (Interactor) чешет репу
func fetchList(request: List.Fetch.Request) {
    // И посылает Герасима (Worker) в лес
    worker?.fetchData { [weak self] result in
        let response = List.Fetch.Response(data: result)
        // Герасим принёс. Теперь надо поэту (Presenter) отдать
        self?.presenter?.presentList(response: response)
    }
}

// 3. Поэт (Presenter) начинает выёбываться
func presentList(response: List.Fetch.Response) {
    // «О, сырые данные! Сейчас я из этого шедевр сделаю!»
    let viewModel = List.Fetch.ViewModel(
        items: response.data.map { $0.title },
        isEmpty: response.data.isEmpty
    )
    // И несёт готовый шедевр холую
    viewController?.displayList(viewModel: viewModel)
}

// 4. Холуй (View) получает красивую картинку и лепит её на стену
func displayList(viewModel: List.Fetch.ViewModel) {
    tableView.reloadData()
    emptyStateLabel.isHidden = !viewModel.isEmpty
}

И что в итоге, блядь?

Плюсы, ёпта:

• Чистота, блядь! Каждый знает своё место. Холуй не лезет в бизнес-логику, управляющий не парится с кнопками. Если что-то сломалось — сразу видно, кто из них мудак.
• Тестируемость — овердохуищная! Поэта и управляющего можно тестировать отдельно, без всей этой iOS-хуйни с интерфейсами. Просто подсунул им данные и смотришь, что отдадут.
• Масштабируется легко. Новую фичу? Добавляй нового Worker'а или расширяй Interactor. Не надо всю избу перестраивать.
• Фреймворк похуй. Бизнес-логика в Interactor'е живёт своей жизнью, ей всё равно, iOS там или Android, или чайник со свистком.

Минусы, а их, блядь, не меньше:

• Бойлерплейта — как говна за баней. Для экрана с одной кнопкой нужно создать, сука, 5-7 файлов! View, Interactor, Presenter, Router, Models, Worker... В рот меня чих-пых! Полдня пишешь не логику, а протоколы да методы передачи данных между ними.
• Выучиться — пиздец. Новый человек в проекте смотрит на эту карусель и думает: «Я нихуя не понимаю, где что». Это не MVC, где всё в одном файле и сразу видно.
• Файловый ад. Один экран — целая папка в проекте. Запутаться проще простого.

Так когда же это говно использовать? А вот когда проект — это не халтурка на неделю, а серьёзная, долгая бандура, которую будут десять человек поддерживать следующие пять лет. Когда тесты — это не «надо бы», а обязательное условие, иначе тебе начальник ебальник набьёт. Когда требования меняются каждую неделю и нужно, чтобы одно поправил — другое не разъехалось.

Для простого экрана с табличкой — это, конечно, из пушки по воробьям, блядь. Но для сложной фичи, где логики на три экрана — самое то. Выбирай с умом, а то получится как с Герасимом: максимализм — это хуйня, потихонечку надо.