0

Princípios S.O.L.I.D

#Boas práticas
Rosemeire Deconti
Rosemeire Deconti

Introdução


Para ser sincera, eu nunca tinha ouvido falar nos princípios S.O.L.I.D, embora, utilizasse alguns deles em meus códigos mesmo sem saber.


Entendi a importância do tema e criei este artigo para consolidar este conhecimento e compartilhar com todos vocês. Meu objetivo é utilizar todos os princípios criando códigos melhores e sem ferir os princípios.


No final deste documento vocês encontram as referências que utilizei para criar este artigo.


Espero que seja útil! Bons estudos! Muito sucesso para todos vocês!


O que significa S.O.L.I.D?

O S.O.L.I.D é um acrônimo que representa os cinco princípios da programação orientada a objetos e design de código teorizados por Robert C. Martin (conhecido como Tio Bob) por volta do ano 2000. Michael Feathers foi responsável pela criação do acrônimo:


SRP Single Responsibility Principle    (Princípio da Responsabilidade Única)


OCP Open/Closed Principle               (Princípio do Aberto/Fechado)


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


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


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


“Os princípios SOLID não são regras. Eles não são leis. Eles não são verdades perfeitas. São declarações na ordem de "Uma maçã por dia mantém o médico longe." Este é um bom princípio, é um bom conselho, mas não é uma verdade pura, nem uma regra.” - Tio Bob


Vantagens por utilizar do S.O.L.I.D.

  •  Fácil manutenção;
  •  Fácil entendimento;
  •  Organização;
  •  Aberta a receber novas funcionalidades sem danos colaterais;
  •  Reaproveitamento de código;
  •  Fácil adaptação a mudanças no escopo do projeto.


Desvantagens por não utilizar o S.O.L.I.D.

  •  Duplicidade de código;
  •  Código sem estrutura coesa;
  •  Dificuldade na manutenção / evolução do código;
  •  Pequenos ajustes podem ocasionar “quebras”;
  •  Dificuldade para executar e criar testes de unidade;
  •  Dificuldade de reaproveitar código para outras aplicações.


Descrição de cada princípio

A seguir descrevo cada princípio com sua definição e as vantagens da utilização.

 

1. Princípio da Responsabilidade Única (SRP)


Definição

Esse princípio diz que um componente deve ter uma única razão para mudar. Isto é extremamente semelhante ao conceito de coesão em orientação a objetos. Uma classe que tem muitas razões para mudar não é coesa, enquanto uma classe com boa coesão provavelmente terá poucas razões para mudar.


Vantagens

  •  Forte Coesão
  •  Um código com uma complexidade menor
  •  Um código mais fácil de se ler
  •  Um código mais fácil de se dar manutenção

 

2. Princípio do Aberto/Fechado (OCP)


Definição

Esse princípio diz que classes, módulos, funções devem ser abertos para extensão, mas fechadas para modificação. Na prática o princípio diz que uma entidade poderá ter seu comportamento estendido sem modificar o seu código original.


Vantagens

  •  Um código mais fácil de se ler
  •  Menor risco de se quebrar uma funcionalidade já existente.

 

3. Princípio da Substituição de Liskov (LSP)


Definição

Esse princípio foi definido por Barbara Liskov, e a sua ideia é que objetos devem poder ser substituídos por instâncias de seus subtipos sem que a funcionalidade seja alterada do ponto de vista do cliente.


Vantagens

  • Validação de que suas abstrações estão corretas
  • Código facilmente reutilizável
  • Um código mais fácil de se ler
  • Hierarquias de classes mais fáceis de se entender

 

4. Princípio da Segregação de Interfaces (ISP)


Definição

Esse princípio diz que classes que implementam interfaces não deveriam ser forçadas a implementar métodos que não vão utilizar. Ao perceber que uma interface está se tornando grande, uma boa ideia é "quebrar" essa interface em várias outras menores mais específicas ao domínio de sua aplicação.


Vantagens

  • Código facilmente reutilizável
  • Um código mais fácil de se ler


5. Princípio da Inversão de Dependências (DIP)


Definição

Módulos de alto nível (ex: lógica de negócios) não devem depender de módulos de baixo nível (ex: operações de banco de dados). Ambos devem depender de abstrações. Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.


Vantagens

  •  Código facilmente reutilizável
  •  Um código mais fácil de se ler
  •  Classes injetadas podem ser facilmente “mockadas” em testes


Referências

Curso “Aplicando design patterns na prática com cSharp da DIO / Avanade


SOLID Principles made easy | Hacker Noon


SOLID design principles explained | by BGL Tech | BGL Tech | Medium


O que é SOLID: O guia completo para você entender os 5 princípios da POO | by João Roberto da Paixão | Desenvolvendo com Paixão | Medium


O que é SOLID? | Venturus


OOD: SOLID para humanos (com exemplos) (adrianolisboa.com)

0
3

Comentários (4)

0
Rosemeire Deconti

Rosemeire Deconti

08/04/2021 13:32

Valeu Lucas! Conheci este tema faz pouco tempo. Gostei muito! Bons estudos!

0
Lucas Santos

Lucas Santos

07/04/2021 22:55

Muito bom, parabéns !! leio bastante sobre esse tema

0
Rosemeire Deconti

Rosemeire Deconti

07/04/2021 12:00

Marcos!

Muito grata pela dica! Vou pesquisar!

Bons estudos e sucesso!

1
Marcos Silva

Marcos Silva

07/04/2021 11:17

Olá, Rosemeire !


Parabéns pelo artigo e pelo interesse em boas práticas de desenvolvimento

Gostaria de sugerir a você, que pesquisasse também sobre " Código Limpo ", acredito que irá gostar.


Sucesso nos estudos !

Apaixonada por tecnologia e informação. Na área desde 1.984 e sem previsão de parada.

Brasil