Programação é uma mistura de arte com ciência, pois demanda do programador uma doses de criatividade e lógica, sem uma metodologia concreta, essa tarefa torna-se passível de falha, por isso ao longo dos anos o mercado começou a padronizar alguns conceitos, criando os Princípios SOLID.
O que ele quis dizer com isso? Simples: você não vai conseguir criar uma roda melhor do que a que já foi criada, então use-a, foque nos problemas reais dos seus clientes, e não em criar um código extremamente rebuscado e como excesso de engenharia.
Quando um programador escreve um código, ele está criando algo a partir do nada, e esse algo pode tanto ser benéfico quanto destrutivo. Ele está impondo ordem ao caos, está dizendo a uma máquina precisamente o que ela deve fazer, ele tem nas mãos então um enorme potencial para causar prejuízos incalculáveis.
Padrões, Padrões e mais Padrões
Os padrões de projetos não surgiram na área de TI, eles foram trazidos de área de arquitetura e engenharia civil. Lá os engenheiros e arquitetos após Séculos de observações, perceberam que em um projeto os problemas se repetiam e que as soluções que funcionavam também. Então eles catalogaram essas soluções e deram o nome de Padrões de Projeto.
Os arquitetos de software logo perceberam que isso também poderia ser aplicado a área de programação, e criaram um catalogo de Padrões de Projeto de Software.
Antes de padrões , tenha princípios
“Padrões não surgem do nada, eles emergem” – JOSHUA KERIEVSKY. Mas como assim emergem? A Orientação a Objetos possui alguns princípios que devem ser seguidos afim de que o seu código tenha o mínimo de qualidade aceitável.
Quando esses princípios são respeitados, os padrões surgem em meio a seu código. Por exemplo, quando vocês reduz a acoplamento entre os objetos, programando para a sua Interface e não para sua implementação, facilmente surgirá o padrão Strategy, sem que haja esforço adicional algum.
Os padrões então foram catalogados observando-se o uso correto dos Fundamentos da Orientação a Objetos. Alguns padrões exigem um pouco de esforço adicional para serem implementados, mas seguindo os princípios SOLID, 90% do seu trabalho está feito.
Os Princípios SOLID
Os princípios SOLID (sólido em inglês) da Orientação a Objetos também foram catalogados, e devido às letras iniciais do nome de cada um dos princípios (nomes em inglês), criou-se esse acrônimo.
Responsabilidade Única (SRP, Single Responsibility Principle), cada classe deve ter uma única responsabilidade.
Aberto para Extensão, Fechado para alteração (OCP, Open/Closed Principle), as classes devem poder ter seu comportamento extendido sem que haja a necessidade de alterar o seu código.
Substituição de Liskov (LSP, Liskov Substitution Principle), instâncias de objetos devem poder ser substituídas por instâncias de seus subtipos, sem que o sistema deixe de funcionar corretamente
Segregação de Interfaces (ISP, Interface Segregation Principle), muitas interfaces especificas , são melhores que uma única interface de uso geral.
Inversão de Dependências (DIP, Dependency Inversion Principle), as classes devem depender de abstrações e não de coisas concretas.
Concluindo
Seguir os princípios SOLID, aumenta a clareza e legibilidade do seu código, facilitando que qualquer outro programador não sofra ao dar manutenção.
Aumenta a coesão de suas classes, evitando que comportamentos inesperados não sejam inseridos sem querer.
Diminui o acoplamento, assim a reutilização real do seu código se torna possível.
Além do mais seguir esses princípios é um claro sinal de profissionalismo, no seu código é sua imagem enquanto profissional que está em jogo, e você não vai querer ser mal visto.