Você que trabalha com ou deseja aprender a programar uma linguagem orientada a objetos, já sabe o que é SOLID?
Ao iniciar um projeto novo, uma equipe de desenvolvedores tende a se animar e quer fazer o projeto da melhor forma possível, englobando tecnologias novas e uma arquitetura de projeto enxuta.
Porém, sabemos que tudo pode mudar rapidamente. Clientes mudam de ideia o tempo todo, o mercado muda e as tecnologias se atualizam, além de que, é importante considerar que talvez as pessoas desenvolvedoras que começaram o projeto não são as que vão terminá-lo.
Para facilitar essas constantes mudanças que a vida de desenvolvimento fornece, é importante adotarmos padrões de projeto, tanto de arquitetura quanto de design e o SOLID é um excelente candidato para melhorar um projeto.
- O que é SOLID e como surgiu esse acrônimo?
- O que é Programação Orientada a Objetos(POO)?
- SOLID: Quais os 5 princípios da POO(Programação Orientada a Objetos)?
- Quais os benefícios de usar SOLID na POO?
O que é SOLID e como surgiu esse acrônimo?
O SOLID é uma junção de princípios e boas práticas que visam melhorar a arquitetura e design de um projeto, além de ter como intuito facilitar sua manutenção e compreensão.
O termo SOLID surgiu após seu criador, Michael Feathers, observar que era possível unificar os cinco princípios da orientação a objeto na sigla SOLID. O acrônimo significa:
Todos esses princípios facilitam o desenvolvimento de um software ajudando as pessoas desenvolvedoras a melhorarem seu código, separando responsabilidades, tornando o código mais limpo e consequentemente mais legível. Também fica mais fácil dar manutenção no projeto, reaproveitar trechos de códigos entre muitos outros benefícios.
O que é Programação Orientada a Objetos (POO)?
Quando uma pessoa está programando, ela está tentando fazer com que o código fique o mais próximo possível do mundo real. A Orientação a Objetos é um paradigma que ajuda as pessoas desenvolvedoras a fazerem essa abstração do mundo real para o código.
Muitos desenvolvedores optam por utilizar POO na programação, pois ela traz uma série de benefícios para o desenvolvedor e principalmente para o projeto. Ela possui 4 pilares:
Abstração
É aqui que entra o que falamos mais acima, a abstração de um objeto do mundo real para o código. Vamos pensar em uma pessoa, quais características ela pode ter? Bom, uma pessoa tem um nome, CPF, RG, data de nascimento… E o que uma pessoa pode fazer? Se mover, falar, comer, entre muitas outras funções.
Abstração em POO fará justamente isso, a compreensão de um objeto que queremos desenvolver de forma singular, tentando aproximá-lo da realidade o máximo possível.
Encapsulamento
Como o próprio nome já diz, o encapsulamento embrulha propriedades de uma classe. Isso porque, às vezes, o desenvolvedor ou desenvolvedora não quer que qualquer parte da aplicação tenha acesso direto àquela classe por questões de segurança.
No encapsulamento, temos as propriedades public, private e protected. Caso quem esteja desenvolvendo opte por tornar a classe privada, a pessoa pode “liberar” o acesso gerando os chamados “getters” e “setter” dos atributos da classe.
Polimorfismo
Dentro da Biologia, o Poliformismo é a necessidade de adaptação da forma fenotípica (anatomia e fisiologia) de plantas e animais com intuito de sobrevivência. Essa palavra, por si só, significa “várias formas”.
Na programação, a intenção é semelhante: Uma classe filha pode herdar atributos da classe pai e modificá-los de acordo com a necessidade de adaptação.
Herança
A herança em POO é extremamente utilizada para a diminuição de código, pois, como o nome já diz, uma classe filha pode herdar funções de uma classe pai minimizando a quantidade de código que teria que ser reescrito.
SOLID: Quais os 5 princípios da POO (Programação Orientada a Objetos)?
S – Single Responsibility Principle (Princípio da responsabilidade única)
O princípio da responsabilidade única enfatiza que uma classe deve ter apenas um objetivo, ou seja, ela deve possuir apenas uma função ou funções similares.
Exemplo do Single Responsibility Principle na prática
Você já foi a um show? Ou já viu alguma gravação de um show? Então, provavelmente você nunca viu uma única pessoa fazendo tudo. Em um show, as responsabilidades são compartilhadas em prol de um objetivo, que nesse caso é produzir uma música de qualidade. O princípio da responsabilidade única é justamente esse, fazer com que uma única classe execute funções que tem haver com aquela classe.
O – Open-Closed Principle (Princípio Aberto-Fechado)
O princípio aberto-fechado traz a ideia de que as classes da aplicação devem ser abertas para extensões e fechadas para modificações, ou seja, outras classes podem ter acesso ao que aquela classe possui, porém, não podem alterá-las.
Isso porque alterar uma classe pai pode ser perigoso, já que outras classes dentro da aplicação podem estar utilizando-a. Ao realizar uma alteração nela, impactará todas as outras que estão utilizando ela.
Talvez você esteja pensando: “e se a minha classe precisar executar uma outra tarefa?” Você pode simplesmente criar uma nova tarefa dentro da classe. A ideia aqui não é não mexer na classe em hipótese alguma, e sim, caso necessário, adicionar uma nova função àquela classe e não alterar o que já existe nela.
Exemplo do Open-Closed Principle na prática
L – Liskov Substitution Principle (Princípio da substituição de Liskov)
Liskov veio de Barbara Liskov, que foi uma cientista americana que trouxe a ideia de que
“As classes derivadas devem ser substituíveis pelas suas classes bases”.
Essa frase em si não é muito explicativa, mas calma que vamos dar alguns exemplos para que faça sentido para você!
Suponhamos que você tenha uma classe Pessoa. Essa classe contém atributos como nome, CPF, RG… Mas, e se você criar uma outra classe chamada Aluno, quais os atributos que a classe Aluno pode conter? Se você pensou em nome, CPF, RG, você está certíssimo, porém, não é interessante criar esses mesmos atributos para a classe aluno, o ideal seria que Aluno herdasse de Pessoa.
Esse é o princípio que traz a ideia de herança. Temos uma classe pai, que geralmente possui atributos genéricos e temos uma classe filha, que herda os atributos da classe pai e pode ter outros atributos específicos para si mesma. No nosso exemplo, a classe Aluno poderia herdar todos os atributos da classe Pessoa e ter também ter outros atributos como nota, presença…
Exemplo do Liskov Substitution Principle na prática
I – Interface Segregation Principle (Princípio da Segregação da Interface)
“Classes não devem ser forçadas a depender de métodos que não usam.”
Quando você aplica o princípio de herança, fazendo uma classe herdar da outra, sua classe filha é obrigada a implementar os métodos da classe pai e como você já deve estar imaginando, isso vai contra os princípios do SOLID, pois não é nada interessante que uma classe implementa métodos que não é útil para ela.
Com o princípio de segregação de interface, é possível implementar somente o que importa para as nossas classes. Vamos imaginar que tenhamos uma classe AtendenteFarmacia, mas esse cargo é dividido em dois, temos o atendente de caixa e o balconista e eles executam funções diferentes, logo, teríamos as classes AtendenteCaixa e Balconista.
O balconista lê a receita e entrega os medicamentos ao cliente. Já o atendente de caixa, passa os produtos no caixa e recebe o pagamento. Se fossemos criar uma interface, teríamos os métodos:
Quando você implementasse essa interface na classe AtendenteCaixa, você teria que implementar todos os métodos, inclusive os métodos que o atendente de caixa não executa.
Para evitar isso, basta criar uma interface que atenda separadamente as funções de cada atendente.
Exemplo da Interface Segregation Principle na prática
D – Dependency Inversion Principle (Princípio da inversão da dependência)
O princípio da inversão de dependência traz a ideia de que
“Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender da abstração.”
“Abstrações não devem depender de detalhes. Os detalhes devem depender das abstrações.”
Em outras palavras, os módulos que são classes de alto nível devem depender de conceitos, também chamadas de abstrações independente de como funcionam, ou seja, a função da inversão de dependência faz com que os softwares se desassociem dos módulos.
Exemplo da Dependency Inversion Principle na prática
Quais os benefícios de usar SOLID na POO?
O SOLID fornece diversos benefícios na hora de criarmos uma aplicação, listamos 3 dos principais para você.
1. Segurança
As classes e aplicação se tornam mais seguras graças a divisão de responsabilidades. Com o SOLID, não corremos o risco de ter classes “quebradas” por que alguém alterou algum método de outra classe.
2. Manutenção
Com responsabilidades divididas, fica muito mais fácil dar manutenção na aplicação, principalmente se a pessoa desenvolvedora que for dar manutenção não for a mesmo que desenvolveu a aplicação. Como cada parte do código fonte está exatamente aonde deveria estar, fica mais fácil entender.
3. Reutilizável
Com POO não é necessária ficar reescrevendo o mesmo código para executar uma determinada tarefa, basta estender de outra classe que já tenha a função que você precisa.
Como vimos, é muito importante entender o SOLID e a programação orientada a objetos, pois, atualmente, a maioria das linguagens utilizam esse paradigma por conta de todos os benefícios que ele traz.
Se você gostou desse artigo, será muito interessante aprender mais sobre Spring Boot. Confira!
