# Solid > Guia de Referência: Princípios SOLID no Desenvolvimento de Software - Skill: `moisesfilho/solid` (Agent Skill) - Install (CLI): `npx skillmds@latest add moisesfilho/solid` - Raw SKILL.md: https://api.skillmd.com/api/skills/moisesfilho/solid/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: moisesfilho (https://skillmd.com/u/moisesfilho) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/moisesfilho/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.