Utilização de Pattern Adapter para desacoplamento de códigos legados no contexto do front-end
Quando trabalhamos em empresas que estão há muito tempo no mercado, encontramos em seu catálogo diversos softwares legados. Esses códigos realmente são bem úteis por conter muitas regras que fizeram a empresa chegar aonde está. Com o decorrer dos anos, as coisas vão mudando e a necessidade de modificá-los vai se tornando alta, uma vez que a tecnologia empregada já não acompanha mais a agilidade necessária que a corporação precisa, ou até mesmo os colaboradores não estão aptos a lidar com tecnologias antigas que acabam por dificultar o desenvolvimento.
É fato que a estratégia utilizada para o desacoplamento desses legados por vezes engloba diferentes padrões para garantir uma boa estrutura arquitetural. Mas vamos às formas como temos encarado esse desafio…
Problema
Tínhamos o desafio de trazer a reatividade para o front-end, pois no nosso cenário as interações com os componentes eram feitas por um único objeto estático disponível por toda a aplicação, causando diversos problemas de efeitos ocultos. No fluxo de reservas de carros temos muitos componentes, o que tornaria inviável realizar todo o desenvolvimento desde o componente até o envio dos dados para o back-end.
Para começar essa modificação, precisaríamos reestruturar as camadas de serviços e APIs que interagem com os componentes.
Estudo de caso
Temos um componente de cliente que possui três campos principais: CPF, nome e código do cliente.
Esse componente é utilizado em diferentes telas e inicialmente não poderíamos realizar a estruturação completa dele, pois as alterações poderiam afetar os dados de outros fluxos trazendo riscos para o projeto.
O adapter funciona literalmente como um adaptador de USBs e HDMIs no nosso dia a dia, ele permite que plugs não compatíveis sejam compatíveis para a utilização e compartilhamento de informações.[2]
Solução
Tá, mas e aí Carol, como faço para utilizar o adapter nesse caso?
A proposta definida foi inserir um adapter de objetos para conseguir garantir as duas formas de comunicação.
1 . Criamos uma interface para padronizar as implementações de adapter
2. Criamos o adapter específico de cliente onde recebemos o objeto legado e transformamos em um objeto novo
3. Nas chamadas onde era necessário enviar os dados de um formato legado para o fluxo novo, realizamos a chamada para adaptar o objeto antes de enviar os dados novos.
Dessa forma, conseguimos desenvolver as demais camadas sem interferência nas camadas que funcionam para o fluxo antigo.
Conclusão
Cada caso é um caso, mas este é um exemplo de como estamos fazendo para conseguir desacoplar do código legado aos pouquinhos, e a grande vantagem disso é que conseguimos posteriormente criar um componente novo e plugar no fluxo novo sem problemas. Para esse caso, podemos remover o adapter, porque podemos implementar o componente considerando a estrutura de um novo objeto.
Gostaria de agradecer em especial ao Gregório Almeida por ter apoiado na construção do trabalho e incentivado o time na utilização de design patterns no front para otimizar a arquitetura dos nossos sistemas.
Referências:
[1] https://www.dofactory.com/javascript/design-patterns/adapter
[2] https://refactoring.guru/pt-br/design-patterns/adapter
