Blog Tecnológico

No artigo passado, aprendemos como aperfeiçoar um programa “Hello, World!” com a inserção de labels, text fields, buttons, sliders, e switches, inclusive inserindo suas ações ao programa. Agora, iremos expandir as possibilidades do seu conhecimento, entendendo o que são os padrões de modelagem ? MVC, MVP e o MVVM.

Entendendo os padrões MVC, MVP e MVVM

Model-View-Controller

Você provavelmente já ouviu falar sobre o View Controller, e também sobre os “padrões”. O View Controller faz parte do “Padrão Model-View-Controller” (Padrão Modelo-Visão-Controlador). Este padrão de arquitetura de software separa a representação da informação da interação do usuário com um aplicativo em três partes, sendo usada para separar representações de informação internas dos modos como a informação é apresentada para e interagida pelo usuário. As responsabilidades são:

• O Model define a estrutura de dados como uma forma de modelagem, atualizando o sistema de acordo com as ações do usuário que interage com o programa. Como por exemplo, o usuário pressiona um botão, e todo o modelo deve ser atualizado à partir desta ação. Com isso, a View é atualizada;

• A View define o display do aplicativo de acordo com o modelo que foi projetado. Utilizando o mesmo exemplo, o usuário interage com um botão dentro de um aplicativo, de uma forma direta sem mexer com código ou modificando o modelo. A View manda a ação do usuário diretamente ao Controller;

• O Controller define a parte lógica da programação. Utilizando o mesmo exemplo, o usuário interage com um botão dentro de um aplicativo, e à partir disto, o que será modificado será a parte do código, que irá entender que um usuário apertou um botão e realizar ações em cima da mesma diretamente no código. O Controller irá manipular o Model à partir da ação, e também pode atualizar diretamente a View, de acordo com as mudanças pertinentes dentro do código.

Model-View-Presenter

Temos também o “Padrão Model-View-Presenter” (Padrão Modelo-Visão-Apresentador), o qual separa o Controller de modo que o acoplamento de View/Activity possa ocorrer sem prendê-lo ao restante das responsabilidades do “Controller”. As responsabilidades são:

• O Model funciona da mesma forma que no MVC;
• A View possui uma única diferença onde o Activity é considerado parte da View em si;
• O Presenter é essencialmente o Controller do MVC. Ele não está vinculado ao View, apenas a uma interface. Isso faz com que o Presenter não gerencia o tráfego de solicitações recebidas, como é feito no Controller.

Model-View-ViewModel

Por último, temos o “Padrão Model-View-ViewModel” (Padrão Modelo-Visão-VisãoModelo), possuindo modularidade e possibilidade de realizar testes de forma mais fácil, ao mesmo tempo em que reduz a quantidade de código que é necessária escrever para conectar o Model com a View. Este padrão suporta ligação bidirecional entre View e ViewModel. As responsabilidades são:

• O Model funciona da mesma forma que no MVC e MVP;
• A View se liga a variáveis do tipo "Observable" e ações expostas pelo ViewModel de forma flexível;
• O ViewModel é responsável por expor métodos, comandos e propriedades que mantém o estado da View, assim como manipular a Model com resultados de ações da View e preparar dados do tipo “Observable” necessários para a exibição. Ele também fornece ganchos para que a View passe eventos para o Model. No entanto o ViewModel não está vinculado à View. Existe uma relação de muitos-para-um entre a View e ViewModel, o que significa que uma ViewModel pode mapear muitas Views.

Afinal, quais dos padrões são utilizados pelo Swift no Xcode?

Tanto o padrão MVC quanto o MVVM podem ser utilizados para padronizar o código e as interfaces dentro do Xcode. É frequente a utilização do MVC devido ao seu uso mais frequente e por ser um padrão mais “tradicional” em relação ao MVVM, até mesmo considerando que o uso da parte do Controller é essencial para qualquer uso de programação.

Apesar disso, o MVVM é também utilizado devido ao uso pragmático de uma categoria “híbrida” entre o Model e a View, fazendo o uso de uma programação mais “dinâmica” e reduzindo a necessidade de focar exclusivamente em uma programação focada apenas em código (Controller), e fazendo uso das ferramentas para tornar o código como sendo um mediador de Model e View. Apesar disso, o Controller ainda sim apresenta benefícios de ser utilizado, mas depende muito do caso de uso em que você está fazendo para seu código.

Gostou deste conteúdo?