SOLID é um acrônimo mnemônico que relaciona um tópico de boas práticas de programação a cada letra. A aplicação desses princípios tem por objetivo deixar o projeto mais coeso, reaproveitável e torna a sua manutenção mais simples. Nesse post, vamos falar sobre o princípio de inversão de dependência. é sobre esse princípio que falaremos nesse artigo!
<div id="toc_container" class="toc_white no_bullets">Sum&aacute;rio<ul class="toc_list"><li><a href="#O-que-e-o-principio-SOLID">1 O que é o princípio SOLID?</a></li><li><a href="#Por-que-usar-SOLID">2 Por que usar SOLID?</a></li><li><a href="#Quais-sao-os-principios-SOLID">3 Quais são os princípios SOLID?</a><ul><li><a href="#SRP-Single-Responsibility-Principle">3.1 SRP — Single Responsibility Principle:</a></li><li><a href="#OCP-Open-Closed-Principle">3.2 OCP — Open-Closed Principle:</a></li><li><a href="#LSP-Liskov-Substitution-Principle">3.3 LSP— Liskov Substitution Principle:</a></li><li><a href="#ISP-Interface-Segregation-Principle">3.4 ISP — Interface Segregation Principle:</a></li><li><a href="#DIP-Dependency-Inversion-Principle">3.5 DIP — Dependency Inversion Principle:</a></li></ul></li><li><a href="#E-por-que-esse-programa-nao-seria-adequado">4 E por que esse programa não seria adequado?</a></li><li><a href="#Como-e-a-implementacao-utilizando-o-principio-de-inversao-de-dependencia">5 Como é a implementação utilizando o princípio de inversão de dependência?</a></li><li><a href="#Conclusao">6 Conclusão</a><ul><li><ul><li><ul><li><a href="#i">6.0.0.1 </a></li></ul></li></ul></li></ul></li></ul></div>
<h2>O que é o princípio SOLID?</h2>
Basicamente, SOLID são <a href="https://www.cms.dtidigital.com.br/entrechaves/entre-chaves-52-solid-primeiros-principios/">cinco princípios da programação</a> orientada a objetos que facilitam no desenvolvimento de softwares, tornando-os fáceis de manter e estender. Esses princípios podem ser aplicados a qualquer linguagem de POO.
A sistemática dos princípios SOLID tornam o software mais robusto, escalável e flexível, deixando-o tolerante a mudanças, facilitando a implementação de novos requisitos para a evolução e manutenção do sistema.
Assista o vídeo para entender melhor:
<iframe title="YouTube video player" src="https://www.youtube.com/embed/mkx0CdWiPRA" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe>
<h2>Por que usar SOLID?</h2>
Os princípios SOLID devem ser aplicados para se obter os benefícios da orientação a objetos, tais como:
<ul>
<li>Seja fácil de se manter, adaptar e se ajustar às alterações de escopo;</li>
<li>Seja testável e de fácil entendimento;</li>
<li>Seja extensível para alterações com o menor esforço necessário;</li>
<li>Que forneça o máximo de reaproveitamento;</li>
<li>Que permaneça o máximo de tempo possível em utilização.</li>
</ul>
Utilizando os princípios SOLID é possível evitar problemas muito comuns:
<ul>
<li>Dificuldade na testabilidade / criação de testes de unidade;</li>
<li>Código macarrônico, sem estrutura ou padrão;</li>
<li>Dificuldades de isolar funcionalidades;</li>
<li>Duplicação de código, uma alteração precisa ser feita em N pontos;</li>
<li>Fragilidade, o código quebra facilmente em vários pontos após alguma mudança.</li>
</ul>
<h2>Quais são os princípios SOLID?</h2>
S.O.L.I.D: Os 5 princípios da POO
S — Single Responsiblity Principle (Princípio da responsabilidade única) 
O — Open-Closed Principle (Princípio Aberto-Fechado) 
L — Liskov Substitution Principle (Princípio da substituição de Liskov) 
I — Interface Segregation Principle (Princípio da Segregação da Interface) 
D — Dependency Inversion Principle (Princípio da inversão da dependência)
<h3>SRP — Single Responsibility Principle:</h3>
<a href="https://www.devmedia.com.br/utilizacao-dos-principios-solid-na-aplicacao-de-padroes-de-projeto/25369">Princípio da Responsabilidade Única</a> — Uma classe deve ter um, e somente um, motivo para mudar. 
Esse princípio declara que uma classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade dentro do software, ou seja, a classe deve ter uma única tarefa ou ação para executar.
Classe que não está de acordo com o SRP:
<pre>public class ClienteController {
public void save(ClienteVO c)
{
if (this.validate(c))
{
ClienteDAO.getInstance().save(c);
this.sendEmail();
}
}
private boolean validate(ClienteVO c) {
if (c.nome.equals(""))
return true;
}
private void sendEmail()
{
MimeMessage msg = new MimeMessage(session);
msg.setFrom(new InternetAddress("email@email.com"));
...
Transport.send(msg);
}
}</pre>
No código acima, tem-se uma fictícia classe ClienteController, onde são criadas algumas funcionalidades relativas a persistência de dados, validação e envio de email.
Apesar do código compilar, a classe ClienteController está desempenhando diversos papéis (responsabilidades) que não são inerentes à ela. Por exemplo, a classe está validando uma informação, persistindo o objeto e enviando e-mail.
Neste contexto, deve-se separar cada funcionalidade em classes, mesmo que a princípio seja gerado acoplamento entre elas. Ou seja, a validação deve ser formada por uma classe cuja única responsabilidade seja validar um campo. Existem diversos tipos de validação, como validar se um campo é nulo ou se um e-mail está escrito corretamente.
Seguindo o princípio, cada tipo de validação deve ser uma classe, já que cada validador é uma responsabilidade única:
Classe que está de acordo com o princípio:
<pre>public class Retangulo extends Figura{
public void area()
{
}
public void desenhar()
{
}
}</pre>
No contexto de uma classe que representa um retângulo, a responsabilidade deste retângulo é conter ações inerentes a ele, sendo que a responsabilidade de desenhar (draw) não é relativa à classe retângulo, mesmo porque uma responsabilidade de desenho é muito específica em relação ao ambiente em si.
A quebra desta responsabilidade pode significar diversos problemas de implementação. No exemplo anterior, se houvesse a necessidade de desenhar um retângulo em ambientes diferentes, possivelmente as classes teriam que ser refeitas, ou então o uso de condições seria utilizado para distinguir o ambiente em si.
<h3>OCP — Open-Closed Principle:</h3>
Princípio Aberto-Fechado — Objetos ou entidades devem estar abertos para extensão, mas fechados para modificação, ou seja, quando novos comportamentos e recursos precisam ser adicionados no software, devemos estender e não alterar o código fonte original.
<h3>LSP— Liskov Substitution Principle:</h3>
<a href="https://dtidigital.com.br/blog/principios-solid-o-principio-da-substituicao-de-liskov/">Princípio da substituição de Liskov</a> — Uma classe derivada deve ser substituível por sua classe base. 
O princípio da substituição de Liskov foi introduzido por Barbara Liskov em sua conferência “Data abstraction” em 1987. A definição formal de Liskov diz que:
<blockquote>Se para cada objeto o1 do tipo S há um objeto o2 do tipo T de forma que, para todos os programas P definidos em termos de T, o comportamento de P é inalterado quando o1 é substituído por o2 então S é um subtipo de T</blockquote>
Um exemplo mais simples e de fácil compreensão dessa definição. Seria:
<blockquote>se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa. — Wikipedia.</blockquote>
Exemplos de violação do LSP: 
Sobrescrever/implementar um método que não faz nada; 
Lançar uma exceção inesperada; 
Retornar valores de tipos diferentes da classe base;
<h3>ISP — Interface Segregation Principle:</h3>
Princípio da Segregação da Interface — Uma classe não deve ser forçada a implementar interfaces e métodos que não irão utilizar. Esse princípio basicamente diz que é melhor criar interfaces mais específicas ao invés de termos uma única interface genérica.
<h3>DIP — Dependency Inversion Principle:</h3>
Princípio da Inversão de Dependência — Dependa de abstrações e não de implementações. 
De acordo com Uncle Bob, esse princípio pode ser definido da seguinte forma:
<blockquote>1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração. 
2. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.</blockquote>
Inicialmente pode parecer um pouco estranho pensar na palavra &#8220;inversão&#8221; presente na nomeação desse conceito. Para entender isso, é importante entender como funcionava o desenvolvimento de software antes da formação desse conceito.
Métodos mais tradicionais de software utilizam uma abordagem em que módulos de alto nível dependem de módulos de baixo nível, ou seja, a política de alto nível aplicada à um objeto de baixo nível depende diretamente de como é esse objeto de baixo nível. Vamos ver um exemplo simples de aplicação desse conceito: imagine um botão e uma lâmpada.
Utilizando um diagrama para ilustrar como um modelo seria implementado sem o principio de inversão de dependência, o modelo ficaria assim:
Em que o botão ligaria a lâmpada, caso ela esteja desligada, e desligaria a lâmpada, caso ela esteja ligada.
<h2 style="text-align: left;">E por que esse programa não seria adequado?</h2>
Simples, o seu programa Button somente seria adequado para ligar ou desligar uma lâmpada. Caso o dono do sistema deseje que esse botão seja utilizado para desligar um portão eletrônico, por exemplo, deve ser feitas grandes mudanças no método do Poll do Button para que o botão passe a funcionar onde ele é necessário. Ou seja, um modulo de alto nível (Button) está dependendo de um módulo de baixo nível (Lamp).
<h2 style="text-align: left;">Como é a implementação utilizando o princípio de inversão de dependência?</h2>
Para isso nos deparamos com outro conceito importante quando o assunto é o princípio da inversão de dependência: a divisão em camadas. Para que seja possível e fique clara a aplicação do princípio de inversão de dependência é necessário que mais um camada seja adicionada. Essa camada será responsável pela intermediação do botão com o modulo da lâmpada, deixando o modelo do sistema da seguinte forma:
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/10/braulio3.png"><img fetchpriority="high" decoding="async" class="aligncenter wp-image-477 size-full" title="princípio de inversão de dependência" src="https://dtidigital.com.br/wp-content/uploads/2015/10/braulio3.png" alt="braulio3" width="515" height="267" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2015/10/braulio3.png 515w, https://www.cms.dtidigital.com.br/wp-content/uploads/2015/10/braulio3-300x156.png 300w" sizes="(max-width: 515px) 100vw, 515px" /></a>
Com isso, o Button fará uma implementação que vai utilizar o turnOn e turnOff oferecidos pelo ButtonServer. Enquanto isso, a Lamp detalhará ao ButtonServer quais os detalhes necessários para que o turnOn e turnOff sejam executados corretamente.
O ButtonServer utiliza o conceito de abstração. Ou seja, as funcionalidades turnOn e turnOff apresentadas por ele serão apenas representativas, abstratas, e somente serão implementadas quando um módulo de baixo nível, ao qual essas funcionalidades são aplicadas, apresentar os detalhes necessários para a execução.
Dessa forma, voltando ao nosso exemplo, caso seja necessário que o botão também seja utilizado para a abertura de um portão eletrônico, somente será necessário adicionar ao modelo um motor. Este representa os detalhes necessários para que as funções turnOn e turnOff direcionadas ao motor do portão sejam executadas. O modelo então fica assim:
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/10/braulio4.png"><img decoding="async" class="aligncenter wp-image-478 size-full" title="princípio de inversão de dependência" src="https://dtidigital.com.br/wp-content/uploads/2015/10/braulio4.png" alt="braulio4" width="672" height="290" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2015/10/braulio4.png 672w, https://www.cms.dtidigital.com.br/wp-content/uploads/2015/10/braulio4-300x129.png 300w" sizes="(max-width: 672px) 100vw, 672px" /></a>
<h2>Conclusão</h2>
Por fim, pode-se observar um isolamento entre a camada de negócios dos detalhes. O comportamento do botão independe completamente de qual objeto ele está ligando ou desligando. Sua lógica de ligar quando está desligado e desligar quando está ligado estará sempre intocada e será aplicada em qualquer um dos casos.
&nbsp;
<h5></h5>

Chegou o momento de impulsionar os resultados da sua empresa! Para entrar em contato com a gente, clique no botão abaixo e preencha o formulário.

Princípios SOLID – O princípio de inversão de dependência

Dê o primeiro passo na jornada da transformação digital

Confira outros artigos