Introdução

Você sabe o que um padrão de projeto de software?

Mais conhecido como Design Pattern, são modelos que podemos seguir para estruturar o código para que fique bem organizado. Quando começamos a aprender programação, fazemos tudo no mesmo arquivo, não é mesmo? Começamos declarando as variáveis, em seguida o que o programa deve fazer com as variáveis e por fim exibe ao usuário o resultado, fazemos tudo no mesmo arquivo uma linha abaixo da outra. Mas e quando o programa começa a ficar maior e mais complexo? Começa a ficar mais complicado!

Para que todo esse conteúdo não fique todo misturado, dividimos o código em diferentes partes dependendo do padrão escolhido, no exemplo mencionado anterior poderíamos colocar as declarações de variáveis em um local, o uso delas em outro e mais um local para apresentar o resultado para o usuário. Então vamos ver exemplos para entender um pouco melhor de três diferentes padrões muito utilizadas no mercado!

Padrões de projeto

MVC (Model-View-Controller)

Nesse padrão dividimos o código em 3 partes, Model responsável pela criação dos objetos, View responsável pela exibição das informações para o usuário e Controller para o comportamento do software.

Vamos considerar um software de cadastro:

Model

A Model é onde se define os objetos, como nome e senha, esses objetos poderão ser usados mais para frente no código.

Não sabe o que é um objeto? Quê tal aprender primeiro o que é Orientação à Objetos neste meu outro artigo?

View

Na View é feito a criação de telas, é onde o usuário estará vendo os campos do formulário de cadastro e interagindo com o programa.

Controller

Já a Controller é responsável pelo que o programa realiza, ela pode, por exemplo, verificar se alguma das caixas de texto ficaram vazias para avisar a View que deixe o contorno delas vermelho e exiba uma mensagem de aviso, e se estiver tudo certo, a Controller faz a verificação de que está tudo correto e envia para a próxima etapa do programa.

MVVM (Model-View-ViewModel)

Neste padrão também temos a divisão em 3 partes e, assim como em MVC, ela também possui Model e View com as mesmas características, o que faz com que muitos confundam as duas.

Model

O Model aqui também é onde definimos os objetos e a lógica de negócios do aplicativo. Por exemplo, no contexto de um aplicativo de cadastro, o Model poderia incluir a definição de um objeto "Usuário" com propriedades como nome, senha, e métodos para realizar operações como salvar ou recuperar um usuário do banco de dados.

View

A View é novamente responsável por exibir a interface gráfica para o usuário. Ela representa a camada de apresentação do aplicativo, mostrando elementos como botões, campos de entrada e textos. Em uma tela de cadastro, a View seria responsável por exibir os campos de nome, senha e botões de envio.

ViewModel

A ViewModel atua como um intermediário entre o Model e a View. Ela prepara os dados para serem exibidos na View e gerencia a interação do usuário. Na tela de cadastro, a ViewModel seria responsável por validar os dados inseridos pelo usuário, formatá-los adequadamente e encaminhá-los para o Model para serem processados. Além disso, ela pode conter lógica adicional para lidar com eventos da interface do usuário, como cliques em botões ou preenchimento de formulários.

Coordinator

O Coordinator é um padrão de design que tem como objetivo gerenciar a navegação e o fluxo de telas em um aplicativo. Ele é frequentemente utilizado em conjunto com outros padrões, como o MVVM-C (Model-View-ViewModel-Coordinator).

No MVVM-C, além do padrão MVVM, adicionamos um componente chamado Coordinator, que é responsável pelo gerenciamento das transições de tela. Isso significa que, sempre que precisamos apresentar uma nova tela ou realizar uma transição entre telas, essa responsabilidade é delegada ao Coordinator.

Por exemplo, em um aplicativo de lista de tarefas usando o MVVM-C, quando o usuário clica em um botão para adicionar uma nova tarefa, em vez de a View lidar diretamente com a transição para a tela de adição de tarefa, essa responsabilidade é passada para o Coordinator. O Coordinator então decide qual tela deve ser apresentada em resposta à ação do usuário e inicia a transição.

VIP (View-Interactor-Presenter)

Na abordagem VIP, o código é dividido em três partes principais: View, Interactor e Presenter. Cada parte desempenha um papel específico na arquitetura do aplicativo, facilitando a separação de responsabilidades e a manutenção do código.

View

A camada View é responsável por exibir a interface do usuário e interagir com o usuário. Ela apresenta elementos visuais, como botões, campos de texto e listas, e recebe eventos de entrada do usuário, como toques na tela ou cliques em botões.

Interactor

O Interactor é o núcleo do aplicativo, contendo toda a lógica de negócios e as regras de negócios. Por exemplo, em um aplicativo de lista de tarefas, o Interactor seria responsável por recuperar, adicionar, editar ou excluir tarefas do banco de dados.

Presenter

O Presenter atua como um intermediário entre a View e o Interactor. Ele recebe dados do Interactor e os formata para serem exibidos na View. Além disso, ele também recebe eventos da View e os encaminha para o Interactor para serem processados. O Presenter também pode conter lógica de apresentação adicional, como formatação de texto ou validação de entrada do usuário.

Conclusão

Cada padrão de projeto tem suas próprias vantagens e é mais adequado para diferentes cenários e requisitos de projeto.

O padrão MVC é amplamente utilizado e oferece uma separação clara de responsabilidades, sendo adequado para aplicativos simples com uma lógica de negócios direta.

Já o MVVM pode ser preferível em aplicativos onde a lógica de apresentação é mais complexa e requer um maior desacoplamento entre a View e a lógica de negócios, adicionando uma camada ViewModel para lidar com a lógica de apresentação de dados.

Por sua vez, o VIP oferece uma abordagem simples e escalável para estruturar o código, sendo útil em aplicativos onde é importante separar claramente as responsabilidades entre a apresentação da interface do usuário, a lógica de negócios e a interação entre elas.

Ao escolher o padrão de projeto adequado para um projeto específico, os desenvolvedores podem melhorar a organização do código, facilitar a manutenção e garantir uma experiência de usuário consistente. Experimentar e entender esses padrões é essencial para o desenvolvimento de aplicativos robustos e de alta qualidade.