# 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.

---

## 1. 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.

---

## 2. 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.

---

## 3. 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.

---

## 4. 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.

---

## 5. 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.

---

## Diretrizes 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.


---

## Roteiro 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.

### Prompt de aplicação

```text
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]
```


### Como 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.

### Exemplo preenchido

```text
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.
```