Solid

Guia de Referência: Princípios SOLID no Desenvolvimento de Software

Este documento serve como base de conhecimento sobre os princípios SOLID, um acrônimo para cinco regras de design de software orientado a objetos, introduzidas por Robert C. Martin (Uncle Bob). O objetivo do SOLID é criar códigos mais legíveis, testáveis, flexíveis e fáceis de manter.

1. S - Single Responsibility Principle (SRP)

Princípio da Responsabilidade Única

Conceito: Uma classe, módulo ou função deve ter um, e apenas um, motivo para mudar. Ela deve possuir apenas uma responsabilidade ou cobrir apenas uma funcionalidade de negócio.

• Problema comum: God Classes (classes que fazem tudo, ex: gerenciam dados, autenticam usuários e enviam e-mails).
• Solução: Quebrar a classe multifuncional em classes menores, focadas em tarefas únicas.
• Exemplo Prático: * Incorreto: Uma classe Pedido que calcula o total, salva no banco de dados e envia um e-mail de confirmação.
  • Correto: A classe Pedido gerencia os itens, uma classe PedidoRepository salva no banco e uma classe EmailService envia a notificação.

2. O - Open/Closed Principle (OCP)

Princípio Aberto/Fechado

Conceito: Entidades de software (classes, módulos, funções) devem estar abertas para extensão, mas fechadas para modificação. Você deve conseguir adicionar novos comportamentos sem alterar o código original.

• Problema comum: Uso excessivo de blocos if/else ou switch/case que crescem toda vez que uma nova regra de negócio ou tipo é adicionado.
• Solução: Utilizar abstrações (interfaces ou classes abstratas) e polimorfismo.
• Exemplo Prático:
  • Incorreto: Uma classe CalculadoraDeDesconto com um switch para verificar se o cliente é "VIP", "Regular" ou "Estudante".
  • Correto: Uma interface Desconto com o método calcular(). Cada tipo de cliente implementa essa interface (DescontoVIP, DescontoEstudante). Para criar um novo desconto, basta criar uma nova classe sem alterar a calculadora.

3. L - Liskov Substitution Principle (LSP)

Princípio da Substituição de Liskov

Conceito: Classes derivadas (subclasses) devem ser capazes de substituir suas classes base (superclasses) sem que isso altere a correção ou o comportamento esperado do programa.

• Problema comum: Herança incorreta ou forçada, onde a classe filha joga uma exceção (NotImplementedException) ou altera radicalmente a lógica de um método herdado.
• Solução: Se a subclasse não consegue realizar todas as ações da classe pai, repense a hierarquia. Use composição em vez de herança ou segregue os comportamentos.
• Exemplo Prático:
  • Incorreto: Uma classe pai Passaro com o método voar(). A classe filha Pinguim herda de Passaro, mas lança um erro em voar(), pois pinguins não voam.
  • Correto: Criar uma interface PassaroQueVoa ou separar as especializações de forma que Pinguim não herde comportamentos que não possui.

4. I - Interface Segregation Principle (ISP)

Princípio da Segregação de Interfaces

Conceito: Uma classe não deve ser forçada a depender de interfaces ou métodos que ela não utiliza. É melhor ter várias interfaces específicas do que uma única interface genérica ("gorda").

• Problema comum: Interfaces gigantescas que forçam classes clientes a implementar métodos vazios apenas para satisfazer o contrato.
• Solução: Dividir a interface grande em interfaces menores e altamente coesas.
• Exemplo Prático:
  • Incorreto: Uma interface DispositivoMultifuncional com os métodos imprimir(), escanear() e enviarFax(). Uma impressora simples que herda dessa interface terá que deixar o método enviarFax() em branco.
  • Correto: Separar em três interfaces independentes: Impressora, Scanner e Fax. As classes implementam apenas as interfaces correspondentes às suas capacidades reais.

5. D - Dependency Inversion Principle (DIP)

Princípio da Inversão de Dependência

Conceito: Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Além disso, abstrações não devem depender de detalhes; detalhes devem depender de abstrações.

• Problema comum: Alto acoplamento. Código de regra de negócio instanciando diretamente classes de infraestrutura (como conexões de banco de dados ou bibliotecas de terceiros).
• Solução: Injetar dependências por meio de interfaces, invertendo o controle do fluxo.
• Exemplo Prático:
  • Incorreto: Uma classe de negócio GerenciadorDeUsuario cria manualmente uma instância de MySQLConnection dentro do seu construtor. (Se o banco mudar para MongoDB, o gerenciador quebra).
  • Correto: GerenciadorDeUsuario recebe em seu construtor uma interface DatabaseConnection. Não importa qual banco está sendo usado por trás, desde que ele respeite a interface contratada.

Resumo dos Benefícios do SOLID

• Manutenibilidade: Alterações em uma parte do sistema não causam efeitos cascata inesperados.
• Testabilidade: Facilidade extrema para criar Mocks e realizar testes de unidade robustos devido ao baixo acoplamento.
• Extensibilidade: O sistema cresce de forma orgânica e modular, aceitando novas features com menor custo de desenvolvimento.
• Reuso de Código: Componentes altamente coesos e desacoplados podem ser reaproveitados em múltiplos pontos do sistema.