Що робить Presenter у MVP?

Патерни проєктуванняMiddle~2 хв читання

В архітектурному патерні MVP (Model-View-Presenter) компонент Presenter - це серце системи, посередник, який керує взаємодією між View (представленням) і Model (моделлю).

Він повністю ізолює логіку застосунку від інтерфейсу, роблячи View "тупою", а код - тестованим і передбачуваним.

1. Головна роль Presenter

Presenter приймає користувацькі дії від View, звертається до Model за даними або виконує бізнес-логіку, і передає результати назад у View.

Він контролює процес, але при цьому не знає, як View візуально влаштована - лише взаємодіє з нею через інтерфейс.

2. Основні обов'язки Presenter

1. Реагує на дії користувача

Отримує події з View (наприклад, "користувач натиснув кнопку").
Визначає, що потрібно зробити: викликати метод моделі, валідацію, завантаження даних тощо.

Приклад: Користувач натиснув "Увійти" - Presenter.onLoginClicked() викликає authModel.login(username, password).

2. Спілкується з Model

Presenter не працює з даними напряму - він викликає Model.
Отримує результат (успішно / помилка / список даних).
Обробляє відповідь і готує її для відображення.

Приклад: Model повернула помилку авторизації - Presenter перетворює її на повідомлення і викликає view.showError("Невірний пароль").

3. Оновлює View

Після отримання даних від моделі - повідомляє View, що і як потрібно відобразити.
При цьому не маніпулює конкретними елементами інтерфейсу (кнопками, текстами) напряму, а викликає методи інтерфейсу View.

Приклад:

kotlin

view.showLoading()
view.showUserProfile(user)
view.hideLoading()

4. Містить презентаційну логіку

Визначає, в якому порядку відбуваються кроки, коли потрібно оновити екран, що вважати помилкою тощо.
Перетворює "сирі" дані моделі у формат, зручний для відображення (наприклад, форматує дату або валюту).

3. Як взаємодіють компоненти MVP

javascript

Користувач
   ↓
  View  →  Presenter  →  Model
          ←──────────────
               ↑
             Відповідь

Користувач взаємодіє з View (наприклад, вводить дані і натискає кнопку).
View викликає відповідний метод Presenter.
Presenter звертається до Model.
Model повертає дані або результат.
Presenter повідомляє View, що потрібно показати.

4. Presenter не знає про View напряму

Щоб не порушити ізоляцію, Presenter працює з View через інтерфейс (контракт):

Приклад на Kotlin:

kotlin

interface LoginView {
    fun showLoading()
    fun showError(message: String)
    fun navigateToHome()
}

class LoginPresenter(private val view: LoginView, private val model: AuthModel) {
    fun onLoginClicked(username: String, password: String) {
        view.showLoading()
        model.login(username, password) { success ->
            view.hideLoading()
            if (success) view.navigateToHome()
            else view.showError("Невірний логін або пароль")
        }
    }
}

Таким чином, View можна підмінити (наприклад, у тестах або при зміні платформи), а Presenter залишиться тим самим.

5. Ключові переваги такого підходу

View повністю відв'язана від логіки - її можна легко змінювати. Presenter можна тестувати без UI. Код стає модульним і читабельним. Model залишається універсальною і може використовуватися повторно.

Підсумок:

Presenter - це сполучна ланка між користувачем, інтерфейсом і даними. Він керує потоком, приймає рішення, форматує результат і повідомляє View, що потрібно відобразити.

Простіше кажучи, Model думає, View показує, а Presenter керує сценою.

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.