Назовите минусы MVP

Проблемы классической реализации MVP в Android-приложении:

• Циклическая зависимость между View и Presenter

В MVP View хранит ссылку на Presenter, а Presenter ссылается на View. Это не так страшно, т.к. Presenter не знает о конкретном классе, реализующем интерфейс View, но факт остается фактом.
Из-за того, что Presenter ссылается на View, время его жизни должно не превышать время жизни View. Presenter обязан остановить все асинхронные операции, до перехода Activity или Fragment в состояние destroyed.
Это приводит нас ко второй проблеме.

• Presenter предоставляет методы для обработки жизненного цикла View

В хорошей реализации MVP Presenter не имеет методов жизненного цикла, таких как onStart()/onStop(). Вместо этого создаются методы типа init() для загрузки и отображения данных и unsubscribe() для отписки от асинхронных вызовов.
При такой реализации Presenter не знает о жизненном цикле, но View должна сама заботиться о вызове этих методов. Если View не вызовет unsubscribe() до отработки метода onDestroy(), то это может привести к утечке Activity.

Продолжим список классических проблем MVP:

• Раздутый интерфейс View
Если экран имеет много элементов и состояний, это приводит к тому, что в интерфейс View добавляется слишком много методов. Presenter будет использовать каждый метод для обновления маленькой части UI экрана.
Эта проблема решается разбиением экрана на несколько MVP компонентов, но иногда сложно найти правильный trade off.

• Сложно сохранять состояние
В правильной реализации MVP состояние хранится в Model. Пользователь делает действие → Presenter получает обновленную Model → Presenter обновляет View. Пользователь поворачивает экран → View пересоздается → Presenter инициализируется → Model возвращает закэшированные данные → Presenter обновляет View в том же состоянии.

В реальности помимо состояния бизнес модели существует состояние View. Например текст, введенный в EditText, но не отправленный на бэкенд, или состояние кастомной View (элемента UI, а не интерфейса MVP).
Если эти данные хранить в Model, то мы получаем раздутую модель, заботящуюся не о бизнес логике, а о логике отображения.
Если сохранять в Presenter, то нужно реализовать логику совмещения состояния View и состояния Model при инициализации. Дополнительно View должна обрабатывать метод onSaveInstanceState().

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