Há muitos anos os desenvolvedores utilizam a POO - Programação
Orientada à Objeto (em inglês, OOP - Object Oriented Design) só que esse padrão
por si só não evita programas confusos ou insustentáveis. Pensando em facilitar
a criação de códigos, Robert C. Martin definiu cinco diretrizes que definem
boas práticas para criação de códigos legíveis e de fácil manutenção, esses princípios
foram chamados de SOLID, essa sigla é acrônimo (iniciais do nome em inglês):
Princípio da responsabilidade única - (Single-responsibility principle)
Uma classe, microsserviços, componentes devem ser
responsável por apenas uma atividade.
Utilizando esse principio você poderá garantir que qualquer alteração que venha
a acontecer no código irá impactar somente seus dependentes diretos.
Princípio aberto-fechado (Open–closed principle)
As entidades de (classes, módulos, funções) devem estar abertas para extensão, entretanto fechado
para modificação. Utilizando esse principio podemos garantir que as alterações
sendo realizadas através de extensão da entidade base nada será afetado no
contexto dos códigos que utilizam a classe original.
Princípio da substituição de Liskov (Liskov substitution principle)
O objetivo desse princípio é verificar que uma subclasse
poderá ser substituída pela sua classe
base sem erros. O principio é uma homenagem a Barbara Liskov, ela definiu que
"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".
Princípio de segregação de Interface (Interface segregation principle)
Crie interfaces
refinadas e específicas, porque elas
são melhores que interfaces genéricas. Não devemos ser forçados a depender das
interfaces que não iremos utilizar. Esse princípio lida com as desvantagens da
implementação de grandes interfaces únicas.
Princípio da inversão de dependência (Dependency inversion principle)
Chega um momento no desenvolvimento de software em que nosso
aplicativo será amplamente composto por módulos. Quando isso acontece,
precisamos esclarecer as coisas usando a injeção de dependência. De uma forma
objetiva o princípio nos faz entender que sempre devemos depender de abstrações e não das implementações.
Alguns problemas que com certeza surgiram por não adotar
esses princípios, serão: repetição de código; código sem estrutura padronizada;
fragilidade para manutenção; dificuldade na execução de testes e com certeza baixo
reaproveitamento..
Abordamos os cinco princípios que todo desenvolvedor deve seguir.
Pode ser assustador no começo, estar em conformidade com todos esses
princípios, porém a máxima é verdade, com prática veem a aderência, e como consequência
terá um enorme impacto na manutenção de nossos aplicativos.
Marcelo Goberto de Azevedo
Arquiteto na GFT Brasil