Benefícios mais comuns entre arquiteturas iOS

O desenvolvimento de aplicativos iOS está cada vez mais popular. Os aplicativos estão mais robustos, as interações mais complexas, as funcionalidades mais desafiadoras e os times cada vez maiores. É fundamental que um novo membro de um time seja capaz de compreender e alterar a base de código de um app de forma fácil e rápida.

Para garantir a sincronia desses times e a manutenibilidade do projeto, assuntos como arquitetura foram introduzidos nas empresas e têm sido altamente fomentados na comunidade desenvolvedora. Essas arquiteturas possuem algumas características que podem beneficiar muito os times de desenvolvimento e os projetos como um todo.

A arquitetura de software define a estrutura de um sistema, a comunicação entre os componentes que o compõe e visa garantir a integridade dos requisitos técnicos e operacionais. A arquitetura adotada pela Apple para o desenvolvimento de aplicativos iOS é o MVC (Model — View — Controller), representada no diagrama abaixo:

Onde:

• View é responsável pelos componentes visuais e por receber ações do usuário
• Model representa os objetos de uma aplicação
• Controller é responsável pela interação entre Views e Models

Na prática, View e Controller são representados em uma única classe, chamada UIViewController, que possui outlets para os componentes visuais, recebe as ações do usuário, além de prover dados e garantir a atualização dos modelos. Visto que o objetivo da empresa é apenas expor suas APIs e exemplificar seus usos, esse arranjo cumpre com seu dever.

No entanto, os aplicativos tomaram novas proporções e muitas vezes são altamente complexos, gerando a necessidade de uma nova maneira de organizar o código para garantir a reusabilidade e manutenibilidade do mesmo. Nesse âmbito, o MVC foi apelidado de Massive View Controller, já que todas as lógicas ficam nessa única classe, e novas propostas surgiram para tentar resolver esse problema. Algumas das propostas mais conhecidas são MVP, MVVM, MVVM-C, VIPER e VIP (também conhecida como CleanSwift).

Apesar de suas particularidades e por algumas abrangerem também a forma de lidar com a manipulação de dados e fluxo de navegação, todas as arquiteturas têm como objetivo principal garantir alguns benefícios. São eles: single responsibility e testabilidade.

Single responsibility

É muito pertinente que, ao desenvolver uma aplicação, exista a garantia da single responsibility, isso é, cada classe deve ser responsável por apenas uma atividade. Logo, View não será responsável por chamadas HTTP e Model não saberá da interação do usuário com a aplicação, por exemplo.

Algumas arquiteturas, como VIPER e CleanSwift possuem camadas específicas para lidar com as requisições a APIs ou gerenciamento de banco de dados. Essas camadas podem ser encontradas pelos nomes middleware, interactor, service, entre outros. A ideia é que essas classes possam ser reutilizadas por diferentes fluxos ao invés de haver a repetição de código em múltiplas partes do código.

A maioria das aplicações contém diferentes telas e fluxos de navegação, por isso as novas arquiteturas procuram maneiras mais eficientes de realizar a orquestração dessas telas. É daí que surgiram termos como coordinator e router, classes que sabem a ordenação das telas e fluxos e quais os dados necessários para a inicialização de cada um deles.

Testabilidade

A popularidade dos testes vêm aumentando e os desenvolvedores estão cada vez mais preocupados com a garantia da qualidade de seus códigos. Através da separação de responsabilidades e isolamento de side effects, que devem ser garantidos pelas arquiteturas, é possível testar cada unidade de código e cada um dos módulos. Isso dá liberdade para que o desenvolvedor possa realizar alterações sem que bugs sejam introduzidos na aplicação.

Existem diferentes tipos de testes. Teste unitário, teste de integração e teste de interface. O primeiro visa garantir que uma unidade de código funciona em isolamento. O segundo, como seu próprio nome diz, visa garantir a integração entre módulos e que essa integração não crie side effects na aplicação. Já o teste de interface costuma ser mais manual e, apesar de sua popularidade no mundo de desenvolvimento, deve ser usado com certa cautela, pois são voláteis e bastante custosos.

Independente da quantidade e quais tipos de testes são aplicados a um projeto, a arquitetura escolhida deve sempre visar o aumento da cobertura de testes do código e a qualidade do mesmo, possibilitando que alterações sejam feitas sem a necessidade de regressões e garantindo ao desenvolvedor a segurança de que o app continua operando com sucesso.

Não necessariamente o seu projeto vai se encaixar em uma dessas opções. Você pode criar a sua própria arquitetura ou adaptar uma existente para atender às características do seu projeto. Toda essa sopa de letrinhas deve servir como inspiração e o fundamental é manter a clareza, organização e separação do código, de forma que a responsabilidade única de cada classe e sua testabilidade sejam garantidas.

Cheers!

Quer receber conteúdos exclusivos criados pelos nossos times de tecnologia? Inscreva-se.