SOLID — Princípio da Inversão de Dependência
Nesse quinto e último artigo sobre SOLID falaremos do último e, na minha opinião, mais importante dos princípios, o Princípio da Inversão de Dependência (DIP — Dependency Inversion Principle).
A teoria do DIP diz que:
High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
Benefícios:
Esse princípio se preocupa principalmente com a redução de dependências entre os módulos de código. Podemos pensar nisso como precisar dos objetos de baixo nível para definir contratos que os objetos de alto nível podem usar, sem que os objetos de alto nível precisem se preocupar com a implementação específica que os objetos de baixo nível fornecem.
Observe que o DIP não é exatamente o mesmo que injeção de dependência.
Exemplo:
Para mostrar a violação desse princípios vamos iniciar usando o exemplo da solução do Single Responsibility Principle (SRP) feito lá no primeiro artigo.
A classe CustomerService, apesar de estar respeitando o princípio da responsabilidade única, está acoplada às classes CustomerRepository e EmailService. A palavra-chave new signifca que o código está dependente de implementações e não de abstrações, portanto sempre que mudamos algo nas classes CustomerRepository e EmailService a classe CustomerService deve ser alterada.
Para resolver esse problema vamos inverter a dependência.
Criamos duas interfaces ICustomerRepository e IEmailService para não dependermos mais diretamente das suas implementações e sim de abstrações.
Estamos recebendo elas pelo construtor e usando sem precisar instanciar nenhuma classe nova deixando nosso código desacoplado.
Desse modo, podemos criar novas implementações para a interface ICustomerRepository por exemplo, que não iremos interferir na CustomerService como mostra a imagem abaixo:
Ainda podemos melhorar nosso código usando injeção de dependência, mas é um assunto mais complexo que não iremos abordar aqui. Lembre que só é possível injetar dependências quando estamos invertendo dependências, por isso esse princípio é muito importante.
Obrigado por chegar até o final dessa série sobre SOLID e espero que tenham gostado. Todo o código pode ser encontrado no meu Github.
Links para todos os artigos sobre SOLID:
Princípio da Responsabilidade Única (SRP)
Princípio Aberto Fechado (OCP)
