DS & II

Capítulo 06 - Princípios SOLID

Leitura de 5 min

🚀 Capítulo 06: Princípios SOLID (Tema: Transformers)

NOTE

Este capítulo utiliza a temática de Transformers para explicar os princípios SOLID. Crie peças modulares e flexíveis que podem se transformar e se adaptar a qualquer nova necessidade sem quebrar o robô inteiro!

1. 🎯 Objetivo da Aula

Compreender os 5 princípios do S.O.L.I.D. para o design de software orientado a objetos, entendendo como eles tornam o código mais fácil de manter, testar e evoluir.

2. 🏢 O Cenário Prático (Seu Desafio)

Os robôs Transformers são incríveis porque são modulares.

  • Eles podem trocar de braço, acoplar novas armas e se transformar de carro para robô em segundos.
  • As peças não são coladas umas nas outras de forma fixa; elas usam encaixes inteligentes e independentes.

Na Engenharia de Software, se você escrever o código todo grudado e dependente, quando precisar mudar uma função (trocar o braço do robô), o sistema inteiro vai quebrar! Para evitar isso, nós usamos 5 regras de ouro criadas por Robert C. Martin (o Uncle Bob), conhecidas pelo acrônimo S.O.L.I.D.. Seu desafio é fazer o seu código ter a flexibilidade de um Transformer!

🧠 Fundamentos: A Teoria Traduzida

🛡️ Os 5 Princípios SOLID:

1. S - Single Responsibility (Responsabilidade Única):

  • Regra: Uma classe (ou arquivo) deve ter apenas um motivo para mudar. Ela deve fazer apenas uma coisa muito bem feita.
  • Analogia: Um robô mecânico só conserta. Um robô guerreiro só luta. Não tente criar um robô que luta, conserta, cozinha e lava a louça ao mesmo tempo (Classe Deus).

2. O - Open/Closed (Aberto / Fechado):

  • Regra: O código deve estar aberto para expansão, mas fechado para modificação.
  • Analogia: Se o Optimus Prime quiser uma arma nova, ele apenas encaixa a arma no braço (expansão). Ele não precisa abrir o próprio peito e refazer os circuitos internos (modificação) para poder usar a arma.

3. L - Liskov Substitution (Substituição de Liskov):

  • Regra: Uma classe filha deve poder substituir a classe pai sem quebrar o sistema.
  • Analogia: Se você precisa de um “Veículo” para uma missão e chamar o Bumblebee (que é um carro), a missão deve funcionar. Você não pode descobrir no meio do caminho que o Bumblebee não anda em estradas normais.

4. I - Interface Segregation (Segregação de Interfaces):

  • Regra: É melhor ter várias interfaces pequenas e específicas do que uma gigante e genérica.
  • Analogia: Não obrigue um Transformer que só anda na terra a ter comandos de “Voar” e “Ejetar no espaço” só porque ele usa a mesma interface de robô. Separe a interface de voar apenas para quem voa!

5. D - Dependency Inversion (Inversão de Dependência):

  • Regra: Dependa de abstrações (interfaces), não de classes concretas.
  • Analogia: As armas dos Transformers devem usar um plugue padrão universal. Assim, qualquer robô pode usar qualquer arma. Se a arma for soldada direto no braço de um robô específico, nenhum outro conseguirá usar.

5. 🛠️ Prática Obrigatória 1: Qual princípio foi violado?

Identifique qual dos 5 princípios SOLID está sendo violado em cada situação:

  1. Você criou uma classe chamada Relatorio que calcula o salário dos funcionários, salva os dados no banco de dados e também gera o arquivo PDF para impressão.
  2. Para adicionar uma nova forma de pagamento (PIX) no sistema, você teve que abrir o arquivo Pagamento.cpp e alterar 50 linhas de código que já estavam funcionando para cartões de crédito.

6. 🛠️ Prática Obrigatória 2: O Robô que Voa

Imagine que você tem uma interface chamada IAcaoRobo com os métodos: Andar(), Atacar() e Voar().

  • Você vai criar a classe para o robô Bumblebee (que não voa). Ele será obrigado a implementar o método Voar() e deixá-lo vazio ou dando erro.
  1. Qual princípio SOLID diz que isso está errado e que deveríamos separar a função de voar em outra interface?

7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 06 EngSoftware) e clique em Commit to main.
  2. Envie para a Nuvem (Push): Clique em Push origin.

8. 📂 Estrutura de Pastas

extra_engenharia_de_software/
├── capitulos/
│   ├── capitulo_06_solid.md
│   └── codigos/
│       └── cap06/
│           └── exemplo_solid.cpp

💡 Checkpoint de Lógica

Os princípios SOLID não são leis matemáticas. São boas práticas. No início, pode parecer que você está escrevendo mais arquivos e mais linhas de código, mas no longo prazo, isso salva projetos gigantescos do caos!

10. 🔥 Desafio de Fixação

Pesquise quem foi Barbara Liskov (a cientista da computação que dá nome à letra L do SOLID).

🔑 Gabarito de Código/Fórmulas

Gabarito da Prática 1:

  1. S (Single Responsibility). A classe está fazendo coisas demais (calculando, salvando e gerando PDF). Deveria ser dividida em 3 classes menores.
  2. O (Open/Closed). O código não estava fechado para modificação. O correto seria criar uma nova classe PagamentoPix sem mexer na classe de cartão de crédito. Gabarito da Prática 2:
  3. O princípio I (Interface Segregation). Ele diz que nenhuma classe deve ser forçada a depender de métodos que ela não usa.

← Capitulo Anterior | Proximo Capitulo →

Visão de gráfico

Backlinks