Clean Swift (VIP): Como organizar melhor nossos códigos
Com o alto número de usuários que nossos aplicativos estão enfrentando nos últimos anos, houve a necessidade de nos readaptarmos no jeito que organizamos nossos softwares. Hoje, para trabalharmos com equipes com diversos desenvolvedores e lançarmos recursos regulamente estes precisam ser super escaláveis! A arquitetura Clean Swift para iOS, foi introduzida por Raymond Law para tentar amenizar tais problemas. Abaixo, esta descrito um pouco sobre seu funcionamento e como ela pode te ajudar a ter um código mais testável e de fácil manutenção. Vamos lá?
A arquitetura Clean Swift, conhecida também como VIP, foi introduzida por Raymond Law através do site http://clean-swift.com, o qual foi embasado pelas ideias do livro Clean Architecture do Uncle Bob. Esta nasceu com o intuito de tirar o peso das ViewControllers e aumentar a testabilidade do código. Cada tela é considarada uma cena (scene) a qual é formada por seis componentes: ViewController, Presenter, Interactor, Worker, Models e Router. A conexão entre todos estes componentes é realizada por meio de protocolos. Na imagem abaixo é possível observar as camadas e as conexões do padrão de projeto Clean Swift:
O ciclo VIP (VIP Cycle)
O nome VIP nasceu da junção das inicias de ViewController, Interactor e Presenter. Estes três componentes quando interligados formam um canal unidirecional de informações conhecidos como VIP Cycle. Este funciona da seguinte maneira: a ViewController envia informações ao Interactor, o qual o Interactor roda a lógica de negócio gerando uma saída que vai ao Presenter. O presenter formata a lógica de saída, fornecendo uma resposta para a ViewController, que acaba renderizando uma view.
Os dados que trafegam entre os três componentes são denominados de Request, Response e ViewModel, estes encapsulam e representam os dados para uma ação específica.
ViewController
A ViewController tem dois importantes papeis dentro do VIP:
- Enviar as ações por meio de modelos de Requests ao Interactor,
- Mostrar em uma view o ViewModel formatado que foi recebido do Presenter ao usuário.
Por exemplo, a ViewController pode enviar ao Interactor uma solicitação de request quando o usuário interagir com o aplicativo, que após ser processado, é respondido por meio de um ViewModel, o qual tem as modificações refletidas na UI. Como você deve ter percebido, a ViewController não tem ideia de quem realiza ou como é realizado o processamento da lógica de negócio do aplicativo, ela é formada apenas por elementos de UI.
Interactor
A função do Interactor é de fazer todo o processamento pesado na cena, este é responsável por fazer requests para a API, fazer cálculos e tratar os erros. Um Interactor frequentemente contém Workers, estes são componentes que irão lidar com todos os requests para a API ou irão interagir com qualquer outro framework, estes geralmente contêm uma tarefa específica e podem ser reutilizados por diversas cenas em diversos Interactors. Ao criar um Worker, você acaba deixando seu código mais testável e acaba tirando a responsabilidade do Interactor de conter todo o processamento pesado. Depois do Interactor realizar seu trabalho, este encapsula o resultado em um modelo de Response o qual é passado para o Presenter.
Presenter
O principal objetivo do Presenter é receber um Response do Interactor e criar uma representação para estes serem apresentados para o usuário na ViewController, esta representação dos dados é passada por meio de um modelo do tipo ViewModel. Um exemplo, é a transformação de um modelo de usuário robusto para um ViewModel que será utilizado em uma ViewController de Perfil, o qual conterá somente as informações que serão utilizadas na tela: como o nome, data de nascimento e o sexo do usuário já formatados em String.
Assim, o ciclo VIP é finalizado! Agora, vamos recapitular algumas coisas:
Model
Como comentado no texto acima, cada comunicação entre os módulos (ViewController, Interactor e Presenter) é realizado por um model/modelo diferente. Entre eles:
- Request: a ViewController constrói um Request e passa para o Interactor. Um modelo deste tipo geralmente contêm inputs de usuário, como os cliques de botões e textos inseridos em campos textuais.
- Response: depois do Interactor finalizar o trabalho que foi trazido a ele por meio do Request, o resultado é encapsulado em um Response o qual é passado para um Presenter.
- ViewModel: depois do Presenter receber os dados do Interactor, ele formata os dados robustos em dados primitivos, como strings e ints. Os quais são passados para o ViewController por meio de uma estrutura chamada ViewModel.
Router
Toda a navegação entre cenas é realizada por meio de Routers. Este é responsável por transitar entre uma ViewController e outra, sendo também o melhor lugar para passar dados entre as cenas. Ao criar o Router, você acaba tirando a responsabilidade da ViewController de fazer a navegação, deixando a mesma apenas com a função de receber os inputs e apresentar os dados ao usuário.
Conclusão
Como você deve ter percebido, o padrão Clean Swift é mais burocrático que o conhecido MVC ou MVVM, mas se bem aplicado, facilita a manutenção do código e a escrita de testes. Existe muitos templates na internet que facilitam a implementação da arquitetura, só devemos tomar cuidado com estes, pois geralmente acabam vindo com muito código boiler-plate, os quais fazem o projeto parecer extremamente burocrático e difícil de se entender.
Um dos recursos mais legais do VIP é a implementação deste fluxo unidirecional de informações, sendo um exemplo claro da implementação do princípio de responsabilidade única (Single Responsibility Principle). Nós como desenvolvedores devemos nos aproveitar de tal recurso, pois o mesmo torna o código muito mais fácil de ser refatorado e testado. O uso dos workers também é bem visto, uma vez que os mesmos podem ser aproveitados em diversas cenas, fazendo o código ser mais reutilizável.
Então, devemos utilizar o Clean Swift em todos nossos futuros projetos? Isto depende, o VIP é uma ótima solução para projetos de longa duração, em que há uma equipe relativamente grande que consiga manter uma estrutura robusta como esta. Se seu projeto apresenta estas características, este padrão de projeto será perfeito para você!
Dúvida ou sugestão?
Se tiver alguma dúvida sobre o tema, ou desejar entrar em contato por qualquer outro motivo:
Thats all, we are done.
happy coding …
