O Princípio da Inversão de Dependência no Angular

Quando estudamos sobre Arquitetura de Software e boas práticas de programação nos deparamos com os princípios do SOLID. Estes 5 princípios nos ajudam a escrever sistemas mais flexíveis e de fácil manutenção.

Ao utilizar um framework completo como o Angular talvez esses princípios podem não fazer tanto sentido, já que temos uma arquitetura bastante opinativa onde é fortemente recomendado seguir certos padrões de desenvolvimento.

A verdade é que podemos sim utilizá-los. Neste artigo mostrarei como a Inversão de Dependência (Letra D do SOLID) pode ser aplicada na sua aplicação Angular.

Resumidamente este princípio defende que nossos módulos de alto nível devem depender de abstrações e não de classes concretas.

Caso de Uso

Imagine uma aplicação Dashboard que possui um módulo de listagem de vendas. Temos também dois perfis: um administrador que tem acesso completo e o comercial que tem um acesso mais limitado. Ambos possuem a mesma Interface Gráfica.

A primeira ideia é utilizar os mesmos componentes para os dois perfis e no serviço de vendas criar condicionais para exibir certos detalhes somente quando o perfil for administrador.

A princípio a solução parece viável, porém e se futuramente tivermos mais perfis com diferentes regras de exibição? Teríamos que incluir vários If’s, deixando nosso código difícil de ser lido e mais suscetível a possíveis erros. Também estamos infringindo o Princípio da Responsabilidade Única. O Serviço de Vendas não deveria ter regras de negócio sobre perfis, somente regras de vendas.

Criando uma abstração

Para resolver o problema criamos uma classe abstrata VendaService de alto nível que possui as assinaturas dos métodos que ela desempenha.

Agora criamos mais duas classes com responsabilidades bem definidas: VendaAdminService e VendaComercialService. As duas herdam de VendaService e precisam ter os métodos dela, porém cada uma com sua regra específica.

Temos a UI com a listagem das vendas representada pelo componente VendaListagemComponent. Como definimos que a listagem será igual para todos então este componente também não tem que enxergar as regras de perfis. Ele somente injetará a classe abstrata VendaService.

Mas se o componente só conhece a classe abstrata de vendas, como iremos utilizar as classes específicas para a listagem de cada perfil?

A resposta está nos módulos onde estas camadas estarão. Dentro do array de providers do NgModule podemos dizer ao Angular qual classe de fato será utilizada em tempo de execução utilizando o useClass.

Temos agora um código desacoplado, onde podemos facilmente alterar ou adicionar novos perfis sem precisar modificar os que já existem. Além disso não foi preciso alterar nada no componente, ele continua fazendo o seu papel que é listar as vendas, independente de qual seja a sua origem.

Aplicação em Bibliotecas Externas

Esta técnica se aplica muito bem também quando instalamos bibliotecas externas. Não precisamos expor os métodos dela diretamente na sua regra de negócio. Ao invés disso criamos uma classe abstrata e fazemos com que a biblioteca implemente-a. Se um dia for preciso trocar a biblioteca basta alterar esta implementação. Falei mais sobre esse assunto neste artigo.