SOLID com PHP

Um conjunto de cinco princípios que são determinantes na construção de um código embasado em boas práticas. Com o SOLID é possível garantir uma maior extensibilidade e manutenção de nossos sistemas.

O SOLID serve basicamente para duas coisas:

  • Medir a qualidade das classes.
  • Guia de parâmetro para refatorar o código legado.

Menção histórica

O SOLID surge com uma série de artigos publicados pelo Robert C. Martin (Ucle Bob) entre a década de 90 e 2000, Robert C. Martin foi o identificador destes cinco princípios.
Logo após, Michael Feathers percebe estes cinco princípios e cria o acrônimo SOLID, sigla que representa os cinco princípios abaixo.

Princípios do SOLID

  • SSingle Responsability (Responsabilidade Única)
  • OOpen/Close (Fechado para modificações aberto para expansão)
  • LLiskov’s Substitution (Substituição de Liskov)
  • IInterface Segregation (Segregação de Interface)
  • DDependency Inversion (Inversão de Dependência)

Responsabilidade Única (Single Responsability)

Este primeiro principio diz basicamente que uma classe deve ter uma única e exclusiva responsabilidade.

Quando refatoramos uma classe onde este principio não é atendido, devemos dividi-la em várias classes até que o objetivo de única e exclusiva responsabilidade seja satisfeito.

Então segue um pequeno exemplo que viola o primeiro principio – Responsabilidade única.

 

O método validateUser() esta violando o principio de responsabilidade única, pois esta adicionando a classe User mais de uma responsabilidade, para resolvermos este problema vamos fazer o seguinte:

 

Criando uma nova classe userValidation responsável exclusivamente por validar usuários nós resolvemos este problema de violação de principio.

CONCLUSÃO: Toda classe deve possuir uma, e apenas uma, responsabilidade.

 

Fechado para modificações aberto para expansão (Open/Close)

Este principio garante construção de classes hierarquicamente fundamentadas! Para tal temos que ter certeza de que nossas classes estão fechadas para modificações e abertas para expansão.

Menção histórica

O primeiro a identificar este principio foi Bertrand Meyer criador da linguagem Eiffel influenciando posteriormente grandes autores como Robert C. Martin (Ucle Bob)  e Michael Feathers.

Vamos usar um exemplo de modulo de autenticação que requer apenas dois campos para fazer login para uma área de administradores, email e senha são os campos. Escrevemos o código e executamos o login para tal usuário.

Porém após um tempo decidimos adicionar uma nova área exclusiva para gerentes, no entanto, precisamos de um novo campo apenas no caso de login de gerentes, este é o campo: código da filial.

Esta classe claramente terá de ser modificada se houver outro grupo de usuários a serem logados como por exemplo o grupo de vendedores. Nenhum programador sensato vai querer modificar uma classe em pleno funcionamento em um método crucial como login.

Vamos ver o que acontece  quando aplicamos o principio – Fechado para modificações aberto para expansão, enquanto escrevemos esse código. Vamos separar o comportamento de login por trás de uma interface e criar classes separadas para authUser e authManager.

Desta maneira, qualquer programador que queira escrever uma nova funcionalidade de login para um novo grupo de usuário, criará sua própria classe de modulo de login e implementará a interface de login.

CONCLUSÃO: Se um código puder ser estendido, escreva de forma que ele não precise ser modificado se surgirem requisitos extras e/ou semelhantes.

Deixe um comentário

Seu endereço de email não será publicado. Os campos obrigatórios estão marcados com *