Direto e simples

Da última vez, abordamos a diferença entre Inversão de Dependência e Injeção de Dependência . Ambos são conceitos importantes que nos ajudam a construir um software melhor. Uma das principais diferenças, no entanto, é que a injeção de dependência é um padrão e a inversão de dependência é um princípio.

Hoje vamos discutir por que essa é uma distinção importante.

O que são Princípios?

Princípios são verdades fundamentais. Eles servem como a base sobre a qual se pode construir sistemas e teorias mais complexos. Quando se trata de criar coisas novas, os princípios são cruciais. Eles nos permitem alcançar resultados exponenciais , conectando os pontos de maneiras novas e antes impensáveis. Os princípios servem como antídoto para a constante mudança no mundo, uma mudança que parece estar se acelerando .
Exemplos de princípios podem ser encontrados em todas as áreas da vida:

• Na Engenharia de Software, temos os princípios de design SOLID .
• Na Psicologia, temos o princípio do prazer .
• Na Física, temos os princípios do movimento .

Padrões são, simplesmente, algo que se repete de maneira previsível.
Nossos cérebros são ótimos para identificar padrões. Não só isso, eles são bons em prever o que esses padrões implicam, usando o pensamento indutivo.
Exemplos de padrões também podem ser encontrados em todas as áreas da vida:

• Na Engenharia de Software, temos padrões de projeto .
• Na indústria da moda, temos padrões como modelos .
• Na natureza, temos padrões visuais de simetria, fractais e muito mais.

Estamos todos procurando por algo estável em que confiar, em alguma verdade subjacente que transcenda o contexto e as tecnologias em mudança. Bem, não procure mais, Princípios são exatamente o que precisamos.

A necessidade humana de comida é um princípio. (Exceto para Breatharians , eles afirmam sobreviver no ar e na luz do sol). Você pode confiar nisso como um axioma, não vai mudar enquanto os humanos continuarem humanos.

Em contraste, a necessidade humana de Pizza é um padrão. Se você andar entre jovens, especialmente jovens engenheiros de software, quase parecerá um princípio – Pizza é incrível e deve ser uma necessidade humana básica. No entanto, como outros padrões, nosso amor aparentemente universal pela Pizza depende do contexto. Se você está de dieta, uma Pizza rapidamente se transforma em um Anti-Padrão – algo a ser evitado a todo custo.

Princípios em Engenharia de Software

No mundo da Engenharia de Software, também temos princípios que nos orientam na hora de projetar software.

Tome Inversão de Dependência como um exemplo. Faz parte dos 5 princípios fundamentais do SOLID . Em poucas palavras - significa que devemos depender de abstrações, não de implementações concretas. Este princípio nos ajuda a projetar software robusto e de fácil manutenção. Não há contexto que nos obrigue a favorecer implementações concretas em vez de abstrações, pois o custo de usar abstrações é insignificante, enquanto o custo de uma mudança para uma implementação concreta é potencialmente ilimitado.

Padrões em Engenharia de Software

O mundo da Engenharia de Software também é cheio de padrões, alguns deles considerados “ruins” e costumamos chamá-los de “Anti-Padrões”, sendo o mais memorável o temido “Código Espaguete”. Enquanto alguns são considerados “bons” e nós simplesmente nos referimos a eles como “Padrões de Design”.

Antipadrões são considerados más práticas, um caminho para problemas e bugs sem fim, um sinal de engenheiros inexperientes. Eles são algo a ser evitado a todo custo. Eles ainda são considerados padrões, pois tendem a acontecer de forma bastante previsível, especialmente com engenheiros inexperientes. No exemplo do “Código Espaguete”, é simplesmente uma manifestação de pensamento desorganizado, que tende a ocorrer naturalmente ao tentar resolver um problema sem planejamento prévio ou experiência.

Padrões de projeto são considerados uma boa prática — usando nossa experiência coletiva como engenheiros de software para encontrar soluções elegantes para problemas comuns. O problema é que, às vezes, até mesmo padrões “bons” podem ser mal utilizados, potencialmente transformando-os em Anti-Padrões.

Padrões de design - o bom, o ruim e o talvez

Existem muitos exemplos de padrões de design, mas como regra geral, um bom padrão de design está enraizado em princípios de design.
Por exemplo, a injeção de dependência é um ótimo padrão de design que nos permite separar a criação do uso. Ele reduz o acoplamento, melhora os testes e está enraizado em princípios de design — é uma implementação do Princípio de Inversão de Dependência.

No entanto, alguns padrões não são tão universalmente aceitos, principalmente porque não estão profundamente enraizados em princípios de design.
Por exemplo, vamos dar uma olhada no padrão Singleton. A maioria das pessoas o considera um padrão de design útil. É usado nos casos em que apenas uma única instância de uma classe é necessária e ter várias instâncias pode ser prejudicial. Esse padrão é útil quando queremos criar uma única instância para um cache, um arquivo de configuração ou um registrador.

No entanto, algumas pessoas o consideram um Anti-Padrão. Uma alegação comum é que o padrão viola o Princípio de Responsabilidade Única (O S em SOLID), uma vez que controla seu ciclo de vida e impõe o comportamento de instância única em si mesmo. Na minha opinião, isso não é exatamente preciso, já que o controle de instância é ortogonal à funcionalidade e SRP se refere à funcionalidade. Uma afirmação mais válida é que Singletons violam o Princípio de Inversão de Dependência, pois você depende da implementação concreta — acessando o Singleton por meio de seus métodos estáticos concretos, em vez de depender de abstrações. Isso leva a um acoplamento rígido que torna nosso código menos sustentável e mais propenso a bugs se ocorrerem alterações.
Isso não quer dizer que o padrão Singleton seja inerentemente ruim, mas se parecer que um padrão está violando princípios, você deve ter cuidado antes de implementá-lo.

O que aprendemos hoje

Na Engenharia de Software, como na vida, temos padrões e temos princípios. Identificar padrões e usá-los para resolver problemas comuns pode ser incrivelmente benéfico. No entanto, padrões que não estão profundamente enraizados em princípios podem se tornar Antipadrões – causando mais problemas do que resolvendo.

Da próxima vez que você estiver aprendendo sobre um novo padrão de design, ou mesmo querendo implementar um já existente, pergunte a si mesmo: Esse padrão está enraizado em princípios de design sólidos (trocadilhos)? Ou poderia causar problemas imprevistos no futuro?

Espero que você tenha achado este artigo útil e, até a próxima vez, mantenha-o direto e simples!