GWT: Интерфейс ведущего MVP

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

1. Ссылка - Что означает программа для интерфейсов, а не реализации?
2. Ссылка — пример WikiPedia для MVP

Еще один ключевой фактор в архитектуре MVP, позволяющий сделать ваш довольно чистый дизайн определяет Presenter interface (как мы уже знаем, красота интерфейса OOP conceptin JAVA).

Presenter интерфейс, который позволяет нашим View и callback входить в presenter при получении события. Интерфейс Presenter определяет следующее:

public interface Presenter<T> {
 void onAddButtonClicked(); 
}

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

private Presenter<T> presenter;
  public void setPresenter(Presenter<T> presenter) {
    this.presenter = presenter;
  }

Наконец, когда ваш PresenterConcreteClass реализует ваш интерфейс presenter, эти implementations сработают.

Помимо чистоты использования интерфейса, также нет никаких причин, по которым вы бы не протестировали свое представление. Вы можете использовать сквозные тесты, но вы также можете просто использовать GWTTestCase, где вы создаете экземпляр представления и используете макет презентатора.

Затем вы сможете проверить, что «когда я нажимаю на эту кнопку, он должен вызывать этот метод из презентатора со значениями X, Y и Z в качестве аргументов» или «когда я вызываю этот метод представления с этими аргументами , то такой виджет должен стать красным, а другой скрыть/свернуть/показать/что угодно».

Я также однажды использовал его для аналогичного создания простого приложения тестового стенда для ручного тестирования пользовательского интерфейса с поддельными данными. Приложение состояло из кнопок для имитации ведущего, вызывающего представление с поддельными данными, и обрабатывало обратные вызовы ведущего из представления с помощью Window.alert или подобных вещей. Вы запустите приложение в своем браузере, нажмете здесь и там и убедитесь, что представление работает должным образом.

Это может быть полезно, когда вы позже добавите поле в форму, чтобы убедиться, что вы правильно связываете его с докладчиком. Вы не хотите настраивать свои GWT-RPC/RequestFactory/любые сервисы от реального докладчика, когда может быть достаточно модульного теста.

2 важные причины, которые приходят мне в голову (могут быть и другие...)

1. Тестирование: тогда вашему докладчику не нужно иметь прямую ссылку на представление, что хорошо, поскольку представление содержит объекты GWT (т. е. любые виджеты), которые нельзя использовать в стандартном примере модульного тестирования: Любой объект GWT должен иметь JS-контейнер (например, браузер или GWTTestCase) для создания экземпляра; Тестовый пример JUnit не может использовать браузер; GWTTestCase работает ОЧЕНЬ медленно, поэтому лучше не использовать его. Без интерфейса Presenter должен был бы ссылаться на методы View посредством прямой ссылки на View; это означает, что при тестировании Presenter вы должны создать экземпляр View, который должен создать экземпляр своих виджетов (которые в этот момент требуют GWTTestCase для виджетов). И все, что вы должны стремиться сделать в первую очередь, это проверить логику, которая должна быть полностью в Presenter, чтобы избежать GWTTestCase... С интерфейсом Display вы можете сделать именно это: сосредоточиться на тестировании Presenter, без усложнение создания экземпляра представления (которое имеет свою степень сложности создания экземпляра) и возиться с этим обязательно с GWTTestCase
2. Имейте несколько представлений для одного и того же докладчика: [Я думаю, вы бы сделали это только в том случае, если у вас разные платформы (например, мобильное приложение или браузер), для каждого из которых требуется собственное представление (начиная с версии мобильного приложения). представления отображается иначе, чем представление браузера, поскольку это разные платформы с разными объектами графического интерфейса)]. Затем несколько представлений будут просто реализовывать интерфейс дисплея по-своему. Тогда один презентер может содержать логику, одинаковую для всех представлений, использоваться для всех различных представлений, и все реализации представлений гарантированно будут следовать одним и тем же ожиданиям (которые являются кодификацией в интерфейсе дисплея) этого единственного презентатора! Это проявление передовой практики ООП по проектированию интерфейсов, на что отвечает @SSR.