Falaaaaaaaa desenvolvedor, tudo bem??? Eu estou tranquilo e hoje vamos dando continuidade a série de artigos “A Fábrica de Arquitetos” dessa vez com um dos padrões mais bacanas da categoria dos estruturais, o Adapter Pattern.

Apesar de parecer complexo ou até mesmo um “anti-pattern” ele resolve problemas cotidianos e bem comuns em diferentes tipos de cenário.

…

O que é?

Frequência de uso: 4/5 — Médio Alto

Da categoria dos padrões estruturais o padrão adapter resolve um problema cotidiano muito comum, que é trabalhar com 2 interfaces incompatíveis juntas, nesse momento você deve estar se perguntando “Como assim trabalhar com 2 interfaces incompatíveis”.

Imagine que você precise gerar um relatório em uma classe ReportService, essa classe de serviço recebe via injeção de dependência a instância da classe Report (que implementa a interface IReport) que gera um relatório, PORÉM, você tem a necessidade de gerar outro tipo de relatório no qual implementa uma interface totalmente diferente da qual você está recebendo via DI.

E agora? O que fazer? É para isso que existe o padrão Adapter, cria – se uma classe ReportAdapter que implementa a mesma interface da classe Report, recebe via injeção de dependência o CustomReport (que implementa a interface ICustomReport) e gera o relatório customizado.

Parece complicado? Para quem nunca se deparou com esse cenário e/ou nunca implementou esse padrão vai parecer um pouco complicado sim, mas vamos para parte prática que vai ficar tudo mais fácil.

Vou deixar logo abaixo o UML do padrão:

…

Mãos no Código!

Bom como de praxe, para exemplificar vou utilizar o exemplo acima, uma classe de serviço que tem necessidade de gerar 2 tipos diferentes de relatórios, porém recebe apenas uma interface.

A primeira classe que a gente precisa implementar é a ReportService, classe de serviço na qual vai chamar a classe que gera o relatório.

Dentro da nossa classe de serviço perceba que recebemos via construtor uma instância que implementa a interface IReport, essa é a nossa interface principal que o adaptador também implementará. 

Beleza, agora que já temos nossa interface, vamos criar nossa classe Report que implementa nossa IReport.

Ótimo, agora que já implementamos o primeiro relatório vamos implementar o segundo tipo de relatório com uma interface diferente.

Primeiro precisamos da interface ICustomReport.

Agora vamos criar a classe que implementa essa interface CustomReport.

Agora vamos criar nossa classe adaptadora, a ReportAdapter é ela que vai permitir a gente trabalhar com IReport e ICustomReport simultaneamente de uma forma elegante e limpa.

E por fim criamos a classe que consome nosso ReportService, no meu caso a Program.cs

OBS: Seria muito mais elegante utilizar um container de injeção de dependência, porém este não é o foco do artigo.

Vamos entender o que vai acontecer aqui, essa classe herda da interface IReport ou seja, ela pode ser injetada no mesmo construtor da nossa classe Report, logo após podemos ver que ela recebe via injeção de dependência uma instância da classe CustomerReport que herda de ICustomerReport e assim consegue executar seus métodos.

Dessa forma conseguimos utilizar as funcionalidades de ICustomReport junto com as funcionalidades de IReport.

…

Conclusão

No artigo de hoje vimos como implementar e um dos diversos cenários no qual pode ser aplicado o Adapter Pattern, podendo ser muito útil em cenários nos quais você precisa atuar com interfaces incompatíveis e/ou não pode alterar certa parte do código na qual precisa trabalhar.

Agradeço a atenção e bons estudos!!!!!

Caso precise entrar em contato, me mande uma mensagem aqui.

Baixe o projeto clicando aqui.