S.O.L.I.D

Nesse artigo vou explicar mais sobre estes fundamentos e trazer algumas ilustrações que vão ajudar bastante no entendimento. Vamos lá?

Rebecca Manzi

2 min

Se você trabalha com POO (Programação Orientada a Objetos), provavelmente já ouviu falar em SOLID.

Além de ser um tema muito frequente em entrevistas técnicas e/ou requisitos para vagas, os princípios do SOLID ajudam a escrever um código mais limpo, profissional, elegível e escalável.

Nesse artigo vou explicar mais sobre estes fundamentos e trazer algumas ilustrações que vão ajudar bastante no entendimento. Vamos lá?

Primeiro de tudo, se você nunca ouviu falar em SOLID, trata-se de um acrônimo (sigla) dos seguintes fundamentos:

Single Responsability (Princípio da Responsabilidade Única)
Open/Closed (Princípio Aberto Fechado)
Liskov Substituition (Princípio da Substituição de Liskov)
Interface Segregation (Princípio da Segregação de Interfaces)
Dependency Inversion (Princípio da Inversão de Dependência)

O criador é o conhecido Engenheiro de Software Robert C. Martin, autor de livros como Código Limpo, Arquitetura Limpa e Design Patterns.

Pelos nomes dá pra ter uma ideia muito superficial dos conceitos, então vou aprofundá-los para te ajudar a entender direitinho 😉

Como citei no início, vou utilizar algumas imagens pra ficar mais didático. As ilustrações utilizadas são da Ugonna Thelma.

S - Single Responsability

O Princípio da Responsabilidade Única defende que uma classe/função/módulo/método deve ter apenas uma única responsabilidade. Se você criar uma função enorme, com várias responsabilidades, fica muito mais difícil pra dar manutenção. Ao alterar uma parte, as outras podem ser afetadas e acabar gerando bugs.

Na primeira imagem, o robô faz várias funções ao mesmo tempo. Já na segunda, aplicando o princípio de Single Responsability, cada robô é responsável por uma única função.

O - Open/Closed

O Princípio Aberto/Fechado diz que uma classe/função/módulo/método deve ser aberta para extensões porém fechados para modificações. Ou seja, você deve estender aquela classe e adicionar algo a mais, e não modificá-la diretamente. Alterando a classe diretamente, pode afetar o comportamento de outras partes da aplicação que utilizam esta classe, sem que seja o objetivo.

Na primeira imagem, o robô consegue cortar com o braço direito, e com uma mudança de comportamento pode pintar. Note que a alteração acaba prejudicando a habilidade anterior (agora ele não pode mais cortar). Já no segundo, aplicando o princípio Open-Closed, após aprimorar o robô consegue cortar E pintar.

L - Liskov Substitution

O Princípio da Substituição de Liskov fala que se o objeto "B" é um subtipo de "A", ele deve ser capaz de substituir o "A" (fazer o que é responsabilidade do seu tipo). Um subtipo é um elemento filho (child), ou seja, é uma classe criada a partir de outra (parent). Nesse contexto, o filho deve ser capaz de processar as mesmas requisições e retornar o mesmo resultado que o pai (ou um resultado do mesmo tipo). É o que chamamos de Herança na POO.

A figura mostra que o robô pai faz café. Na parte de baixo, ele não está disponível, então é solicitado café ao robô filho. Sem aplicar o princípio Liskov Substitution, o filho não consegue entregar o café, oferecendo apenas água. No segundo caso, aplicando o princípio, ele oferece um capuccino (note que não é exatamente um café igual ao que o pai faz, mas é do mesmo tipo).

I - Interface Segregation

Segundo o Princípio da Segregação de Interfaces, uma classe não deve requerer ações desnecessárias, ou que não podem ser realizadas. O correto é dividir estas ações em funções específicas para cada tipo de necessidade.

Na imagem acima, as mesmas funções são atribuídas aos dois robôs, porém um deles não tem capacidade de executar todas por não ter antenas. Ao aplicar o princípio de Interface Segregation, cada função está separada de forma que só serão executadas aquelas que atendem às necessidades e características de cada robô.

D - Dependency Inversion

Segundo o Princípio da Inversão de Dependência, classes de níveis mais altos (que executam uma ação com uma ferramenta) não devem depender de classes de níveis mais baixos (necessárias para executar a ação). Ambas devem depender da abstração (interface que contém ambas). Da mesma maneira, a abstração não deve depender de detalhes (como a ferramenta funciona), e sim o contrário - detalhes depende da abstração. Dessa forma, é reduzida a dependência entre os níveis através da utilização da interface.

Na imagem acima, vemos que no primeiro caso o robô executa a ação de cortar a pizza com uma ferramenta específica (o braço cortador de pizza). Já no segundo, em que o princípio de Dependency Inversion é aplicado, o robô corta a pizza com qualquer ferramenta que ele receba

Embora alguns princípios sejam parecidos, seus objetivos são diferentes. De qualquer forma, todos são importantes e devem ser aplicados em conjunto para um projeto mais limpo e escalável.

Bastante informação, né? Se é seu primeiro contato com o tema talvez fique um pouco confuso. 😅 Mas calma, não precisa decorar tudo de uma vez só. Aos poucos isso vai se tornando natural. Já deixa o link do artigo salvo nos favoritos pra relembrar quando for necessário.

Obrigada por ler até aqui e nos vemos na próxima!

Learn

Support

More Options