Interfaces, Interfaces everywhere

Este texto é sobre Dependency Injection (DI) e Interfaces e foi motivado pela minha experiência com Spring durante +-3...

Dextra

View posts by Dextra
Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes. A Dextra faz parte da Mutant, empresa B2B líder no mercado brasileiro e especialista em Customer Experience para plataformas digitais.
Data de publicação: 11/11/2013

Este texto é sobre Dependency Injection (DI) e Interfaces e foi motivado pela minha experiência com Spring durante +-3 anos. As observações abaixo se aplicam também à outros mecanismos de DI e IoC como Guice e Dagger.

Sempre trabalhei com Spring da forma “padrão”. Resumindo: quando você quer injetar uma classe o senso comum diz para você fazer o seguinte:

 

O padrão é criar uma interface para todos os Spring beans. Não por acaso uma aplicação Spring típica possui um zilhão de interfaces e cada uma com apenas uma implementação.

Pouca gente percebe que as interfaces não são obrigatórias e nesses casos nem mesmo são necessárias para atingir dois dos princiais objetivos de DI:

  • Desacoplamento. O uso da interface neste exemplo não é o que garante desacoplamento, garante é que você consegue trocar as implementações com pouco impacto. Reitero que na  maioria dos casos essas interfaces possuem somente uma implementação. Em relação à dependência o que temos é que a classe CaixaServicesImpl precisa de uma Classe/Implementação/Estrutura/Whatever que forneça um método público findEnderecoEntrega com determinada assinatura.
  • Testabilidade. Você não precisa de interfaces para criar Mocks, os frameworks de Mock atuais já conseguem mockar classes concretas e se você precisar escrever o Mock na mão basta fazer override dos métodos da superclasse antes da injeção (inclusive métodos protected).

E se tentássemos suprimir as interfaces e ao mesmo tempo usar um vocabulário mais DDD? Ficaria assim:

O código fica mais limpo e o grau de acoplamento é o mesmo (lembre-se que a relação Interface <=> Impl aqui é 1 <=> 1).

Minha conclusão é que precisamos de uma interface quando… precisamos de uma interface (!): minha classe “usuária” (no exemplo FrenteDeCaixa/CaixaServicesImpl) pode trabalhar com implementações diferentes de uma interface de acordo com determinada regra (aqui entraria a Factory e/ou uma injeção mais sofisticada). Para a imensa maioria dos casos (Services, Facades, DAOs, etc..) não é disso que precisamos.
 
E se depois de um tempo eu descobrir que terei duas implementações possíveis do Cadastro de Clientes? Aí você extrai uma interface e cria as duas implementações, é um refactoring bem simples de fazer !!
 
O super uso de interfaces em frameworks de DI é mais um vício de implementação do que algo que traz ganho real (até mesmo o EJB na sua versão 3.1 tornou as interfaces opcionais). Portanto antes de criar uma Interface faça a boa e velha pergunta: isso é realmente necessário?

 

 

Dextra

View posts by Dextra
Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes. A Dextra faz parte da Mutant, empresa B2B líder no mercado brasileiro e especialista em Customer Experience para plataformas digitais.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

dezessete − onze =

Posts relacionados

  1. Sobre a Dextra

    Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes.

  2. Categorias

Scroll to top