Используйте функции высшего порядка Kotlin в MVP - PullRequest
Новая
       21

Используйте функции высшего порядка Kotlin в MVP

3 голосов
/ 22 марта 2019

Обычно в Java мы создаем интерфейс *Contract для взаимодействия между Представлением и Presenter , например:

MainActivity
как View

public class MainActivity extends Activity implements MainContract {

@Override
public void onCreate(Bundle b) {
   presenter.requestData();
}

@Override
public void showData(String data) {
   // Handle data ...
}

MainPresenter
как Presenter

public class MainPresenter {

   public void requestData() {
      contract.showData("data");
   }
}

MainContract
как interface

public interface MainContract {
   void showData(String data);
}

Поскольку у Kotlin есть функция «Функция высшего порядка» , должна , мы просто передаем функции для управления взаимодействием между представителем и презентатором?Это может быть что-то вроде:

Просмотр: 

presenter.requestData { data ->
   // Handle data
}

Ведущий: 

fun requestData(handler: (String) -> Unit) {
   handler("data")
}

Я не спрашиваю о возможности, я спрашиваю, если этолучшая практика или нет.

1 Ответ

2 голосов
/ 22 марта 2019

Ответ на этот вопрос больше связан с архитектурными решениями, чем с техническими ограничениями.Вы можете реализовать то же самое в Java (даже в Java7) с анонимными экземплярами (при условии, что это будет иметь гораздо больше шаблонного образца и будет труднее читать).

Идея в MVP заключить контракт, заключающийся в том, чтоВнедрение заключается в том, что каждый докладчик знает, как извлекать, манипулировать и представлять в указанный контракт.Потенциально представление может реализовывать несколько контрактов и иметь нескольких докладчиков.Также каждый экземпляр презентатора работает только с одной реализацией контракта, но у вас может быть два экземпляра, обслуживающих две разные реализации.

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

Например, представьте презентатора, который асинхронно выбирает данные и кэширует их в памяти:

  1. Представление вызывает метод презентатора fetchData().
  2. Ведущий вызывает метод showLoading() контракта.
  3. (проходит некоторое время)
  4. Ведущий вызывает методы контракта hideLoading() и showData(data).
  5. Пользователь взаимодействует и снова запускает fetchData()
  6. Докладчик вызывает showData() с кэшированными данными

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

Важно помнить, что в MVP в идеале обаView и Presenter взаимодействуют друг с другом через интерфейсы, и в этом случае интерфейс Presenter не должен зависеть от деталей реализации и просто раскрывать, какие действия они могут выполнять.

...