Avaliar rigidez, fragilidade, imobilidade e viscosidade
Use este guia como lente principal para esta situação.
SOLID e dependências Guia para IA
Princípios de Design e Padrões de Projeto
Princípios de design OO, gestão de dependências, coesão/acoplamento e padrões arquiteturais.
- Autor
- Robert C. Martin
- 39 páginas
- Formato do guia
- Markdown no padrão dos modelos originais + instruções operacionais para IA
Orientação
Como utilizar este .md
Não apenas “anexe e peça para programar”. Dê papel, contexto e critérios.
Anexe o .md junto com o requisitoO guia passa a ser a referência de engenharia para aquela tarefa.
Descreva contexto e restriçõesStack, estrutura atual, legado, prazo, compatibilidade, usuários e comportamento que não pode mudar.
Peça diagnóstico antes de soluçãoA IA deve identificar o problema e escolher somente os princípios relevantes.
Implemente em passos verificáveisEvite reescrita ampla. Peça testes, critérios de aceite e plano de rollback quando necessário.
Faça revisão contra o guiaNo final, peça divergências, riscos, trade-offs e pontos ainda não cobertos.
Casos de uso
Quando este guia é especialmente útil
Aplicar OCP, LSP, DIP e ISP nas fronteiras corretas
Use este guia como lente principal para esta situação.
Reorganizar dependências e pacotes
Use este guia como lente principal para esta situação.
Escolher abstrações que realmente protegem de mudanças
Use este guia como lente principal para esta situação.
warning Limite de uso
Não transforme todo ponto do código em interface; abstraia onde existe volatilidade ou fronteira relevante.
Não transforme todo ponto do código em interface; abstraia onde existe volatilidade ou fronteira relevante.
Prompt pronto
Modelo para começar
Use o guia “Princípios de Design e Padrões de Projeto” anexado como referência para analisar este projeto. Antes de alterar código: 1. Faça um diagnóstico do problema no contexto do projeto. 2. Identifique quais princípios do guia realmente se aplicam. 3. Compare a solução atual com uma alternativa mais simples. 4. Proponha uma mudança incremental e reversível. 5. Defina testes e critérios de aceite. 6. Ao final, revise a implementação contra o guia e liste trade-offs. Contexto: [DESCREVA o sistema, stack, estado atual e cenário da mudança] Objetivo: [DESCREVA o resultado observável que deve existir ao final] Restrições: [DESCREVA o que não pode mudar, compatibilidade e limites técnicos]
Exemplo preenchido — o que o usuário pode descrever
Use o modelo acima com dados concretos do projeto. O exemplo abaixo mostra o nível de detalhe esperado.
Contexto: Módulo de relatórios conhece diretamente banco de dados, envio de e-mail e detalhes de PDF; qualquer mudança exige editar várias classes. Objetivo: Reorganizar responsabilidades e dependências para reduzir acoplamento e permitir novas saídas sem modificar regras centrais. Restrições: Não criar interfaces sem motivo; manter compatibilidade com o código atual; aplicar abstrações somente nas fronteiras que realmente variam.
ContextoStack, versões, arquitetura, página/módulo afetado, estado atual e comportamento existente.
ObjetivoResultado observável para o usuário ou para o sistema; diga o que deve funcionar ao final.
RestriçõesO que não pode mudar, compatibilidade, segurança, acessibilidade, performance, prazo e limites de escopo.
1. Diagnosticar
Peça análise do código e do problema antes de aplicar qualquer padrão ou princípio.
2. Decidir
Exija justificativa: por que esta técnica é adequada e quais alternativas foram descartadas.
3. Verificar
Finalize com testes, checklist, riscos e critérios de aceite.