Guia de Referência: Princípios de Design, Dependências e Padrões (Robert C. Martin)

Este guia consolida os princípios apresentados para evitar que mudanças de requisitos deteriorem o design. O foco é administrar dependências, proteger políticas importantes e estruturar componentes que possam evoluir sem cascatas de alterações.

subdirectory_arrow_right1. Sintomas de Design Deteriorado

• Rigidez: Uma mudança simples exige muitas outras mudanças.
• Fragilidade: Alterar um ponto quebra partes aparentemente não relacionadas.
• Imobilidade: Componentes úteis não podem ser reutilizados sem trazer dependências indesejadas.
• Viscosidade: É mais fácil fazer uma solução incorreta/hack do que seguir o design pretendido.

subdirectory_arrow_right2. Princípios de Classes

• OCP: Módulos devem estar abertos para extensão e fechados para modificação; abstrações são pontos de articulação.
• LSP: Implementações/subtipos devem poder substituir o contrato sem quebrar expectativas do cliente.
• DIP: Dependa de abstrações; políticas de alto nível não devem depender diretamente de detalhes voláteis.
• ISP: Clientes não devem depender de operações que não utilizam; prefira contratos coesos e focados.

widgets3. Princípios de Componentes e Pacotes

• REP: A unidade de reutilização deve ser coerente com a unidade de release.
• CCP: Agrupe classes que mudam pelas mesmas razões para concentrar o impacto das mudanças.
• CRP: Não force clientes a depender de classes que não usam.
• ADP: Dependências entre componentes/pacotes não devem formar ciclos.
• SDP: Dependências devem apontar para componentes mais estáveis quando isso protege políticas.
• SAP: Componentes estáveis devem possuir abstrações suficientes para continuarem extensíveis.

deployed_code4. Padrões como Ferramentas de Dependência

• Abstract Server: Insere abstração entre cliente e servidor para inverter uma dependência direta.
• Adapter: Converte uma interface para a forma esperada pelo cliente.
• Observer: Desacopla origem de eventos de múltiplos interessados.
• Bridge: Separa abstração de implementação para permitir evolução independente.
• Abstract Factory: Cria famílias de objetos sem acoplar o cliente às classes concretas.

school5. Como Usar com IA

Anexe este arquivo ao definir módulos, contratos e dependências. Peça à IA um mapa de dependências, identifique a política que precisa ser protegida e exija justificativa antes de introduzir interfaces ou novos componentes.

subdirectory_arrow_rightDiretrizes de Execução para IA

Ao criar, revisar ou reestruturar uma aplicação, garanta:

1. Mapeie dependências antes de adicionar abstrações.
2. Proteja políticas estáveis de detalhes voláteis usando DIP quando houver fronteira real.
3. Evite ciclos entre pacotes/componentes.
4. Use interfaces com propósito, não como regra mecânica para toda classe.
5. Valide LSP com testes de contrato quando houver múltiplas implementações.

schoolRoteiro de Uso Operacional com IA

1. Contextualize o projeto: informe domínio, stack, arquitetura atual, restrições e objetivo da mudança.
2. Selecione o recorte: diga qual princípio/capítulo deste guia deve orientar a tarefa; não aplique tudo ao mesmo tempo.
3. Peça diagnóstico antes do código: a IA deve identificar sintomas, riscos, dependências e alternativas.
4. Defina critérios de aceite: comportamento, testes, acessibilidade, performance, segurança ou operação conforme o tema.
5. Implemente incrementalmente: mudanças pequenas, reversíveis e verificadas.
6. Faça revisão final: peça à IA que confronte a solução com este guia e liste desvios deliberados.

smart_toyPrompt de aplicação

Use este guia como referência técnica para a tarefa abaixo.
Não copie regras mecanicamente. Primeiro diagnostique o problema e selecione apenas os princípios aplicáveis.
Mostre: (1) diagnóstico, (2) decisão, (3) implementação proposta, (4) testes/verificações, (5) trade-offs e (6) checklist final.

Contexto: [DESCREVA o sistema, stack, estado atual e cenário da mudança]
Objetivo: [DESCREVA o resultado esperado e o comportamento que deve existir]
Restrições: [DESCREVA limites de escopo, compatibilidade, segurança, prazo e o que não pode mudar]

schoolComo preencher os campos

• Contexto: descreva o tipo de sistema, stack/versões, arquitetura atual, onde a mudança acontece e o comportamento relevante já existente.
• Objetivo: descreva o resultado observável que deve existir ao final, não apenas a tecnologia que você quer usar.
• Restrições: informe o que não pode mudar, compatibilidade, prazo, segurança, acessibilidade, performance, legado, dependências e limites de escopo.

lightbulbExemplo preenchido

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.