MVP Android – Сколько докладчиков?

У меня есть быстрый вопрос. Я пытаюсь (и боюсь) разрабатывать свое приложение с шаблоном проектирования MVP.

Могу ли я спросить, должен ли я иметь отдельный класс презентатора для каждого вида (активности, фрагмента)?

Ресурсов, которые я могу видеть в Интернете, не так много, что ясно показывает образцы MVP. Может ли кто-нибудь поделиться, если у них есть?

PS Я также использую RecyclerViewAdapter в этом приложении, поэтому любые указатели на это будут оценены

заранее спасибо

Solutions Collecting From Web of "MVP Android – Сколько докладчиков?"

Дизайн Model-View-Controller появился очень рано в программном обеспечении и первоначально использовался для таких элементов, как элемент кнопки. Вы используете MVP (в основном то же, что и MVC), чтобы получить архитектуру, которая является модульной и, следовательно, легко поддерживать, разделяя представление из логики.

Учитывая ваш вопрос, я думаю, что вам действительно нужен один класс за просмотр. Это будет наиболее распространенный подход.

http://antonioleiva.com/mvp-android/ дает теоретический обзор MVP.

Хотя старый, это очень интересный вопрос. Поскольку в настоящее время MVP / MVC / MVVM является своего рода «гудкими словами» в сообществе Android, этот вопрос заслуживает более полного ответа (IMHO).

Короткий ответ:

Один презентатор может использоваться с несколькими видами

Длительный ответ:

В общем, нет ни одного единого определения MVP / MVC – существует много подходов к реализации этих архитектурных шаблонов. Вы не указали определение «своего» MVP, поэтому я могу только догадываться, что вы имеете в виду.

Тем не менее, существуют некоторые «лучшие практики» в объектно-ориентированном программировании, которые должны (в идеале) учитывать любую реализацию любого архитектурного шаблона.

Вы спрашиваете, можете ли вы повторно использовать реализацию одного презентатора с разными видами, не так ли? Давайте рассмотрим этот вопрос через призму принципов SOLID .

«L» означает «Принцип замещения Лискова» (LSP). Это один из самых непонятых принципов в SOLID, но общая идея этого принципа гласит следующее:

LSP: если кусок кода работает с объектом класса A, он также должен работать без проблем с объектами любого подкласса A (т. Е. Подклассы должны использоваться вместо A везде)

Пример нарушения LSP в Android – это Context : сублицензии Context (например, Application и Activity ) не эквивалентны. Некоторый код, который требует, чтобы Context мог работать без проблем с Application , но если вы перейдете к Activity вместо этого, произойдет утечка памяти (это очень распространенная ошибка в приложениях Android, которая вызвана прежде всего нарушением LSP разработчиками Google).

Верните свой вопрос. Я предполагаю, что ваш презентатор выглядит так (обратите внимание на интерфейс для просмотров):

 public class SomePresenter { /** * Views bound to this presenter must implement this interface */ interface SomeView { void doSomething1(); void doSomething2(); } public void bindView(SomeView someView) { // view binding logic } // more presenter's methods } 

LSP заявляет, что любой класс, который реализует SomeView может использоваться с SomePresenter . SomeView не должно волновать, осуществляется ли реализация SomeView это Activity , Fragment или, может быть, просто макет для модульного теста.

Итак, полный ответ на ваш вопрос: один ведущий может быть повторно использован с разными представлениями, если ведущий не зависит от конкретных реализаций представлений, а только от их суперкласса.

Дополнительная информация:

Я бы предположил, что вы задали свой вопрос, потому что, с одной стороны, вы считали, что один ведущий должен иметь возможность работать с разными взглядами (просто подумайте об испытании A / B разных пользовательских интерфейсов), но, с другой стороны, Факт, что взгляды – Activity и Fragment заставили вас чувствовать себя некомфортно с этой мыслью.

Мое личное мнение заключается в том, что в MVC / MVP ни Activity ни Fragment должны быть представлениями. Обоснование этой претензии обобщается в этом сообщении: « Почему в Android не являются элементами пользовательского интерфейса .

Введите описание изображения здесь

Я также предлагаю вам взглянуть на другой подход к внедрению MVP в Android – если вы воспользуетесь этим, вам будет очевидно, что ведущий должен иметь возможность работать с разными представлениями, и вы не будете Есть это чувство «что-то не так».

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

  public abstract class BaseActivity<Presenter extends BasePresenter> extends AppCompatActivity { protected Presenter mPresenter; @NonNull protected abstract Presenter createPresenter(@NonNull final Context context); @Override protected void onCreate(final Bundle savedInstanceState) { super.onCreate(savedInstanceState); mPresenter = createPresenter(this); mPresenter.onCreate(savedInstanceState); } } // other lifecycle methods 

А затем создайте абстрактный BasePresenter

 public abstract class BasePresenter { protected BasePresenter() { } @NonNull public static BasePresenter nullPresenter(@NonNull final Context context) { return new BasePresenter() {}; } @CallSuper public void onCreate(@Nullable final Bundle savedInstanceState) { } 

Теперь, создавая активность, сделайте следующее:

 public class MyActivity extends BaseActivity<MyActivityPresenter>{ @Override MyActivityPresenter createPresenter(@NoNull final Context context){ return new MyActivityPresenter(all, Your, Dependencies, Here); } } 

Теперь просмотрите это видео и поймите ответственность Activity / View в MVP.