D — Dependency Inversion Principle (Princípio da inversão da dependência)
Qual é o programador em sã consciência que não deseja um software que seja flexível e que possa ser incrementado e corrigido sem maiores danos ao escopo global do projeto? Isto existe? Sim! E o Tio Bob nos facilitou com uma dica muito importante cuja leitura e entendimento é super fácil!
“O código que implementa uma política de alto nível não deve depender do código que implementa detalhes de nível mais baixo”.
Mas…não se surpreenda ao ouvir que “as coisas não são tão fáceis quanto parecem ser”. Ora, Tio Bob, como assim? Seria muito fácil abstrair do mundo real em busca do mundo ideal e na história temos uma imagem simbólica deste embate muito forte que é a “peleia” de Platão com Aristóteles: enquanto Platão aponta para o mundo ideal Aristóteles aponta para o mundo real. Como procedemos? O que fazemos neste caso? Nosso entendimento deve ser completo para não cairmos em armadilhas. O que buscamos com o princípio da inversão de dependência é estabilidade!
Quando construímos software o terror de todo programador é fazer manutenção e esta prática é realizada todo santo dia. Sim, nós passamos mais tempo corrigindo ou alterando software do que construindo coisas novas. Imagine você alterando uma pequena parte de um código fonte e de repente milhares de linhas adicionais são afetadas e quebram seu software literalmente ao meio. O que se faz? Senta e chora? Não! Vamos buscar entender direito o que está em jogo. A primeira coisa que precisamos entender é que,
Evidentemente, é impraticável tratar essa ideia como uma regra, pois os sistemas de software dependem de muitas facilidades concretas. (…) a classe String é muito estável. (…) Toleramos essas dependências porque sabemos e confiamos que elas não mudarão.
Não se preocupe, vamos encontrar um meio termo para explicarmos o que está ocorrendo neste momento. Para além da “revolução ideológica” da guerra entre “abstrações e implementações”, o que buscamos é uma alternativa para podermos trabalhar com eficiência, com excelência, rapidez e estabilidade em software. Parece mágica, porém, não é. E a estratégia é muito simples. Veja:
“Em uma interface abstrata, toda a mudança corresponde a uma mudança em suas implementações concretas. (…) bons designers e arquitetos de software trabalham duro para reduzir a volatilidade das interfaces”.
Em outros termos o que buscamos com a inversão de dependência é controle e estabilidade para trabalharmos com mais tranquilidade, digamos. Isto favorece também o trabalho coletivo, já que diminuímos radicalmente a dependência e melhoramos o diálogo traduzido em “coesão” de atores e contextos. Como diria o ditado “um voo em avião maior sempre vai ser mais estável que um teco-teco”. No entanto, precisamos nos balancear para começarmos a entender que a estabilidade é algo que se constrói em software. Traduzindo,
O componente abstrato contém todas as regras de negócio de alto nível da aplicação. Por sua vez, o componente concreto contém todos os detalhes da implementação que essas regras de negócio manipulam.
Finalmente, o princípio de inversão de dependência propicia maior produtividade sem maiores prejuízos. Obviamente, é mais um dos conselhos do Tio Bob que podemos aproveitar sempre que for possível. Obviamente, como demonstramos acima, não podemos ser radicais na aplicação deste princípio, pois, muitas implementações são usadas diariamente e suas dependências tornam o processo de escrita de software ágil e eficiente.
Porém, lembre-se que ainda assim temos muitos arquitetos, engenheiros e programadores de software trabalhando duro para que esta “estabilidade” possa ser compartilhada dentro das linguagens. Vale dizer: até que ponto nós conseguimos atuar com bons contratos para melhorar nossa estabilidade dentro de nossos times?
"O Fecha" do Estudo
Depois de tudo eu também me perguntei: “Mas eu vou para o TDC “só” com isto?” De fato estas pequenas dicas me tomaram um grande tempo de dois anos de estudo para fixar bem o alguns dos conceitos. É vergonhoso? Não! Vergonha é não tentar. Como diz o ditado “Vergonha é roubar uma melancia grande e não aguentar levar ela embora”.
Existe uma lacuna entre o final da educação formal e a empregabilidade. Temos um caminho possível para evitar o colapso: Ensinar as pessoas com as melhores práticas e me parece que o Tio Bob já vivia uma situação similar. E não há prejuízo em não tentar resolver este problema, prejuízo neste caso é continuar com este problema.
Como iniciamos? Com o método “PP — Paciência & Persistência”. Temos que ter paciência para estudar e aprender e persistência para desenvolvermos soluções que possam ser funcionais com algum valor para outrem.
Embora existam muitas críticas com relação aos Princípios elencados no SOLID ainda assim podemos tomá-los como “conselhos” de quem se dedicou a fazer software de qualidade e também que se dedica a documentar especialmente suas falhas no intuito de ajudar os menos experientes neste caminho de produção de programas de computadores. Fato é que, além da viciante leitura, os conselhos do Tio Bob são aplicáveis todos os dias em algum nível de problemas que estamos resolvendo.
Ninguém assume que o início da vida de programador é difícil. É por este motivo que eu recomendo fortemente que os iniciantes façam a leitura atenta destes princípios. Até aceito o argumento de que eles já estão obsoletos frente às modernidades que existem no século XXI. No entanto, não vou aceitar qualquer tipo de argumento sem que pelo menos uma leitura atenta seja feita.
As sugestões presentes neste compêndio chamado de “princípios” ainda são muito relevantes, especialmente para aqueles que ainda não tem uma real noção ou nunca tiveram contato com grandes projetos. Neste sentido, a contribuição do Tio Bob continuará sendo importantíssima para todos nós.
Ademais, se tudo mudou, ainda prestamos nossa homenagem a quem realizou esta tentativa teórica que marcou gerações e tanto nos ensinou e nos incita nosso pensamento a mudar. Convido-vos para o mundo da leitura, da interpretação e da escrita!
Design de software é como uma sanfona: ou se trabalha junto ou não sai a música.
***
S.O.L.I.D
Acrônimo de:
Simplicidade
Mutabilidade
Aplicabilidade
Capacidade
Estabilidade
Finalmente…
Criar software de maneira correta é difícil. Requer conhecimentos e habilidades que a maioria dos jovens programadores ainda não adquiriu. Requer um grau de raciocínio e insight que a maioria dos programadores não se empenha em desenvolver. Requer um nível de disciplina e dedicação que a maioria dos programadores nunca sonhou que precisaria. (…) Quando você acerta o software, algo mágico acontece: você não precisa de hordas de programadores para mantê-lo funcionando.
Fim.
Quer conversar mais sobre este artigo?
https://www.linkedin.com/in/alexandre-klock-ernzen-5484319/
Artigos sobre SOLID:
Introdução > https://medium.com/@bracinho2/solid-introdu%C3%A7%C3%A3o-6b4dbdacdb87
S > https://medium.com/@bracinho2/srp-single-responsability-principle-8d9a68bbae76
O > https://medium.com/@bracinho2/ocp-open-closed-principle-cc21cb168707
