A Arquitetura MVP — Model View Presenter

O MVP nos ajuda a separar nosso código em camadas para termos um código melhor estruturado.

Definição padrão:

MVP é um padrão de desenho de interface de usuário projetado para facilitar os testes unitários automatizados e melhorar a separação de interesses em lógica de apresentação: Model é uma interface que define o modelo de dados que será exibido ou alterado na interface do usuário. View é uma interface que exibe de fato os dados (o modelo) e guia os comandos do usuário (eventos) à camada Presenter para atuar sobre os dados. A interface Presenter atua sobre a Model e a View. Ela recupera os dados dos repositórios (modelo), e os formata para exibi-los na View.

A Model é a camada responsável pela modelagem e manipulação de dados do app. Classes POJO (com atributos públicos) e Beans (com atributos privados e getters/setters) são usadas para modelar dados que vieram de uma fonte remota (JSON de uma API Rest, por exemplo) e que vão ser armazenadas numa base de dados no app.

A View(Activity/Fragment) é a camada responsável por exibir os dados da model na UI e capturar as interações do usuário com o app.

A Presenter trabalha como um controlador entre a Model e a View. Ela será responsável por capturar as ações do usuário com a UI, capturar os dados da Model e devolver para a UI. Geralmente, é criado um contrato entre a View e a Presenter para deixar a responsabilidade de cada uma bem definida.

O Contrato

O contrato nada mais é que uma interface contendo os métodos de UI (que alteram ou capturam atributos de uma view) e os métodos da Presenter, que estão diretamente relacionados com a realização das funcionalidades em si (as operações de um cadastro, por exemplo).

Com a criação deste contrato já conseguimos planejar a estruturação do nosso código quebrado em diferentes métodos, o que ajuda a prevenir o famoso código spaghetti. A view deverá ser burra, isso significa que a activity/fragment terá métodos que alteram a UI mas é a Presenter que controlará a execução deles. Ou seja, uma View sabe exibir/esconder itens da tela (por exemplo), mas é a Presenter que diz quando e como ela irá fazê-los.

Isso também traz outra vantagem: o desacoplamento. Diminuímos a dependência entre as classes, afinal estamos dependendo de uma abstração (contrato), e não da classe concreta (que contém a implementação). Caso precise refatorar a View ou a Presenter é só fazer uma nova implementação baseado no contrato que a substituição ocorrerá sem grandes problemas. Além disso, o desacoplamento nos permite realizar testes automatizados em nosso app.

---