Crie códigos limpos e claros utilizando SOLID. Os 5 princípios para te destacar como profissional.

Dentro da Programação Orientada a Objetos, o SOLID é um conjunto de princípios que vai te ajudar a escrever códigos cada vez mais limpos, escaláveis e de fácil manutenção. Estes princípios vêm ganhando força no mercado, e os profissionais que o aplicam ganham destaque no mercado de trabalho. Os princípios do SOLID podem ser aplicados a qualquer linguagem de programação em sistemas orientados a objetos.

Estes 5 princípios apareceram pela primeira vez em um trabalho apresentado por Robert J. Martin nos anos 2000, mas a abreviação SOLID foi apresentada anos mais tarde por Michael Feathers. SOLID é um acrônimo para 5 responsabilidades:

S - Single Responsibility Principle (SRP) - Princípio de Responsabilidade Única

O - Open-Closed Principle      (OCP) - Princípio Aberto-Fechado 

L - Liskov Substitution Principle  (LSP) - Princípio da Substituição de Liskov 

I - Interface Segregation Principle (ISP) - Princípio da Segregação de Interface

D - Dependency Inversion Principle (DIP) - Princípio da Inversão de Dependência

A princípio parece complicado, mas à medida que vamos utilizando, estes princípios ficam cada vez mais claros e fáceis de entender. 

SRP - Single Responsibility Principle - Princípio da Responsabilidade Única

O princípio da responsabilidade única sugere que cada classe ou função precisa ter apenas uma única responsabilidade. No exemplo a seguir temos a classe de Usuario, ela possui os campos de email e senha como atributos desta classe, e os métodos Getter e Setter destes atributos:

Se eu desejar imprimir os atributos, e criar uma função de imprimir atributos, estarei acrescentando uma responsabilidade a mais para a classe Usuario: 

Portanto, aplicando o princípio SRP, devemos ter uma nova classe:

Uma dica importante é que o nome da função ou classe já descreve o que ela faz, se no nome é difícil explicar o que ela faz, é provável que esteja errado.

OCP - Open-Closed Principle - Princípio de Aberto-Fechado

O princípio de aberto-fechado sugere que nossas classes e funções devem estar abertas para extensão e fechadas para modificação. No código a seguir, temos uma classe de cálculo de salários conforme seu cargo:

Dessa forma, se precisarmos adicionar um novo cálculo de salário para estagiário, teremos um novo else if, e é isto que o princípio OCP sugere que evitamos, criando uma classe abstrata com o método abstrato de calcular salário, e todas as classes que fazem este cálculo poderão herdar e sobrescrever este método:

LSP - Liskov Substitution Principle - Princípio da Substituição de Liskov

O princípio da substituição de Liskov ou LSP, sugere que, se um objeto do tipo T é uma extensão do objeto base S, para todo o programa a subclasse T pode ser substituída pela classe base S sem alterar o funcionamento. Parece difícil mas não é, vamos ao exemplo:

As classes Carro e Moto foram estendidas da classe Veiculo, portanto, ao longo do código, as funções que receberem como parâmetro as classes Veiculo, poderão receber Carro ou Moto, porque ambos são derivados da classe principal, e vice-versa: 

ISP - Interface Segregation Principle - Princípio de Segregação de Interface

De um modo geral, o ISP sugere que uma classe não deve ser obrigada a implementar métodos que não irá utilizar:

Observe que a interface iVeiculo possui o método abstrato Re(), assim, todas as classes que implementam essa interface obrigatoriamente terão que implementar o método Re(), mas é aí surge um problema: Nem todo veículo tem a marcha ré.

A interface possui métodos mais genéricos aos veículos, e as classes que implementam essa interface, terão apenas métodos que realmente irão utilizar.

DIP - Dependency Inversion Principle - Princípio da Inversão de Dependência

O princípio de inversão de dependência sugere que não dependamos de implementações mas de abstrações. Os módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração. Observe o exemplo a seguir: 

No construtor da classe Resetar Senha, é criada uma instância de conexão com o banco de dados, gerando assim um alto nível de acoplamento, e toda vez que eu precisar mudar a conexão com o banco, preciso alterar todas as classes que possui essa instância.

Neste caso, o ideal é que eu tenha uma interface de conexão com o banco de dados e o método de conexão dentro dela. Cada classe de bancos diferentes implementa esta interface, sobrescrevendo este método com a sua própria forma de conexão. 

Para o construtor da classe ResetarSenha, passo a interface de conexão com o banco, e não importa a esta classe qual banco está sendo utilizado, pois tudo já está sendo resolvido pela própria interface.

A princípio parece complexo e difícil de entender, mas a prática facilitará tudo. O primeiro passo sempre é o mais difícil, então comece a usar, que em breve vai ser automático a aplicação destes princípios. Comece pelo mais fácil, refatore seus código trocando os nomes das funções para perceber se pode mudar alguma coisa.

A aplicação dos princípios de SOLID deixam nosso código escalável, flexível, fácil de manutenções e fácil para implementar novas funcionalidades e métodos. Estes princípios, aplicados juntamente com técnicas de Clean Code, trazem qualidade nos seus códigos e te destacam no mercado de trabalho!