# Guia de Referência: Padrões de Projeto GoF (Gamma, Helm, Johnson e Vlissides) Este guia apresenta o catálogo GoF como vocabulário para problemas recorrentes de design. A IA deve selecionar um padrão pela intenção, aplicabilidade, consequências e pelo aspecto do sistema que precisa variar sem exigir um redesenho amplo. --- ## 1. Como Selecionar um Padrão * **Problema:** Comece pelo problema concreto e pelas forças de mudança, não pelo nome do padrão. * **Intenção:** Compare a intenção do padrão com o que precisa ser desacoplado, criado, composto ou coordenado. * **Aplicabilidade:** Confirme que os sinais do padrão existem no projeto atual. * **Consequências:** Avalie complexidade adicional, indireção, número de classes e impacto em testes. * **Variação:** Pergunte o que deve poder mudar independentemente sem reprojetar o sistema. * **Relações:** Compare padrões semelhantes, complementares e alternativos antes de decidir. --- ## 2. Padrões Criacionais ### Abstract Factory * **Intenção:** Criar famílias de objetos relacionados sem expor classes concretas. ### Builder * **Intenção:** Construir objetos complexos passo a passo, permitindo representações diferentes. ### Factory Method * **Intenção:** Delegar para subclasses/implementações a decisão de qual produto concreto criar. ### Prototype * **Intenção:** Criar objetos copiando uma instância prototípica. ### Singleton * **Intenção:** Garantir uma única instância e um ponto de acesso; use com cautela por causa de estado global e testabilidade. --- ## 3. Padrões Estruturais ### Adapter * **Intenção:** Converter uma interface para outra esperada pelo cliente. ### Bridge * **Intenção:** Separar abstração de implementação para que ambas evoluam independentemente. ### Composite * **Intenção:** Representar hierarquias parte-todo e tratar objetos individuais e composições de modo uniforme. ### Decorator * **Intenção:** Adicionar responsabilidades dinamicamente por composição. ### Facade * **Intenção:** Expor uma interface mais simples para um subsistema complexo. ### Flyweight * **Intenção:** Compartilhar estado intrínseco para reduzir custo de muitos objetos semelhantes. ### Proxy * **Intenção:** Controlar acesso a outro objeto, incluindo lazy loading, acesso remoto, cache ou proteção. --- ## 4. Padrões Comportamentais ### Chain of Responsibility * **Intenção:** Passar uma solicitação por uma cadeia de possíveis manipuladores. ### Command * **Intenção:** Encapsular uma solicitação como objeto para fila, histórico, desfazer ou parametrização. ### Interpreter * **Intenção:** Representar a gramática de uma linguagem simples e interpretar sentenças dessa linguagem. ### Iterator * **Intenção:** Percorrer uma coleção sem expor sua representação interna. ### Mediator * **Intenção:** Centralizar um protocolo de colaboração para reduzir dependências entre muitos objetos. ### Memento * **Intenção:** Capturar e restaurar estado sem violar encapsulamento. ### Observer * **Intenção:** Notificar múltiplos assinantes quando o estado/evento de um sujeito mudar. ### State * **Intenção:** Alterar comportamento quando o estado interno muda, encapsulando comportamentos por estado. ### Strategy * **Intenção:** Encapsular algoritmos intercambiáveis e selecionar a estratégia conforme o contexto. ### Template Method * **Intenção:** Definir o esqueleto de um algoritmo e deixar etapas variáveis para subclasses. ### Visitor * **Intenção:** Adicionar operações a uma estrutura de objetos sem modificar as classes dos elementos. --- ## 5. Como Aplicar * **Leia o padrão:** Entenda intenção, aplicabilidade e consequências antes de codificar. * **Mapeie participantes:** Traduza nomes abstratos para nomes do domínio real. * **Implemente o mínimo:** Não crie todos os participantes se uma versão reduzida resolver. * **Teste a variação:** Garanta que o aspecto que motivou o padrão possa mudar com impacto localizado. * **Documente:** Registre a decisão quando o padrão alterar a arquitetura ou o vocabulário do projeto. --- ## 6. Como Usar com IA Use este arquivo como seletor conceitual e combine-o com o arquivo individual do padrão escolhido. Peça à IA que compare pelo menos uma alternativa mais simples e um padrão relacionado antes de implementar. --- ## Diretrizes de Execução para IA Ao criar, revisar ou reestruturar uma aplicação, garanta: 1. **Não force padrões** onde uma solução direta é suficiente. 2. **Selecione pela variação que precisa ser encapsulada** e pelas consequências. 3. **Use nomes do domínio** para participantes e responsabilidades. 4. **Combine padrões somente quando cada um resolver uma força distinta**. 5. **Preserve testabilidade e direção das dependências** ao aplicar padrõ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 cálculo possui vários if/switch por tipo de regra e novas variações são adicionadas com frequência. Objetivo: Avaliar se um Design Pattern reduz a mudança necessária e, se justificar, propor a aplicação mais simples. Restrições: Comparar com solução sem padrão; evitar novas abstrações sem variação real; preservar testes e fronteiras arquiteturais. ```