Os Princípios SOLID em Imagens — Ugonna Thelma

Se você conhece a Programação Orientada a Objetos, provavelmente já ouviu falar dos princípios SOLID.

Esses 5 princípios de desenvolvimento de software são sugestões para se construir softwares que sejam mais fáceis de escalar e manter.

Todos popularizados pelo engenheiro de software, Robert C. Martin.

Há ótimos artigos online sobre SOLID, mas raramente vejo exemplos ilustrados. Isso torna difícil, para estudantes visuais como eu, aprenderem enquanto permanecem envolvidos.

Portanto, o objetivo desse artigo é compreender cada um desses princípios usando imagens.

Pois, alguns deles podem parecer semelhantes, mas não possuem a mesma finalidade. Por exemplo, é possível satisfazer um princípio enquanto viola outro (mesmo que sejam parecidos).

Para tornar a leitura mais simples, usarei a palavra “Classe”. Mas, nesse artigo, ela também pode se aplicar a uma Função, Método ou Módulo.

Agora, vamos começar!

Tradução do artigo “The S.O.L.I.D Principles in Pictures” de Ugonna Thelma.

Os Princípios SOLID

S — Single Responsibility (Responsabilidade Única)

Uma Classe deve ter uma única responsabilidade.

Se uma Classe tiver muitas responsabilidades, ela possui mais chance de ter erros. Porque alterar uma de suas responsabilidades, pode afetar as outras sem que você saiba.

Objetivo

Esse princípio busca separar comportamentos para que, se surgirem bugs após uma mudança, isso não afete outros comportamentos não relacionados.

O — Open-Closed (Aberto-Fechado)

As classes devem ser abertas para extensão, mas fechadas para modificação.

Alterar o comportamento de uma Classe afeta todos os sistemas que usam essa Classe.

Então, se você deseja que a Classe execute mais funções, a abordagem ideal é acrescentar essas funções e NÃO alterar às que já existem.

Objetivo

Esse princípio busca estender o comportamento de uma Classe, sem alterar seu comportamento existente. Isso evita causar bugs onde a Classe estiver sendo usada.

L — Liskov Substitution (Substituição de Liskov)

Se S é um subtipo de T, então objetos do tipo T em um programa podem ser substituídos por objetos do tipo S sem alterar nenhuma das propriedades desse programa.

Pode causar problemas quando uma Classe filha não executa as mesmas ações que sua Classe pai.

Se você tem uma Classe e cria outra a partir dela, então ela se torna pai, com a nova Classe sendo sua filha.

Nesse caso, a Classe filha deve conseguir fazer tudo o que a Classe pai pode fazer. (esse processo é chamado de Herança)

Sendo assim a Classe filha deve processar as mesmas solicitações e entregar o mesmo resultado que a Classe pai ou entregar um resultado do mesmo tipo.

A imagem mostra que a classe pai entrega café (pode ser qualquer tipo de café). Portanto, é aceitável que a Classe filha entregue Cappucino, porque é um tipo específico de Café.

Mas, por exemplo, NÃO seria aceitável entregar Água!

E caso a Classe filha não atenda esses requisitos, significa que ela foi alterada completamente e viola esse princípio.

Objetivo

Esse princípio busca impor consistência para que a Classe pai ou sua Classe filha possam ser usadas da mesma maneira sem erros.

I — Interface Segregation (Segregação de Interface)

Uma classe não devem ser forçada a implementar métodos que não utiliza.

É um desperdício quando uma Classe é obrigada a executar ações inúteis. Além disso, pode produzir bugs inesperados se essa Classe não tiver a capacidade de executar essas ações.

Portanto, uma Classe deve realizar apenas as ações necessárias para cumprir seu papel. Qualquer outra ação deve ser removida completamente ou movida para outro lugar (caso possa ser usada por outra Classe no futuro).

Objetivo

Esse princípio busca dividir um conjunto de ações em conjuntos menores para a Classe executar SOMENTE as ações que precisa.

D — Dependency Inversion (Inversão de Dependência)

1. Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
2. Abstrações não devem depender de detalhes. Os detalhes devem depender de abstrações.

Em primeiro lugar, vamos definir os termos de forma mais simples:

• Módulo (ou Classe) de Alto Nível: Classe que executa uma ação com uma ferramenta;
• Módulo (ou Classe) de baixo nível: A ferramenta necessária para executar a ação;
• Abstração: Representa a interface que conecta as duas Classes;
• Detalhes: Como a ferramenta funciona.

Nesse princípio, uma Classe não deve se fundir com a ferramenta que usa para executar uma ação. Em vez disso, ela deve se fundir à interface que permite a ferramenta se conectar à Classe.

Além disso, tanto a Classe quanto a interface não devem saber como a ferramenta funciona. No entanto, a ferramenta precisa atender às especificações da interface.

Objetivo

Esse princípio busca reduzir a dependência entre uma Classe de alto nível e uma Classe de baixo nível, introduzindo uma interface.

Resumo

Nesse artigo, discutimos os 5 princípios SOLID e destacamos seus objetivos. Eles devem ajudar você a tornar seu código fácil de ajustar, estender e testar com pouco ou nenhum problema.

Muito obrigada por ler. Espero que você tenha compreendido melhor esse tema e tenha se divertido lendo tanto quanto eu escrevendo.

Se você tiver alguma dúvida ou sugestão, deixe um comentário: