Prévia Markdown
Guia de Referência: Padrões de Projeto GoF (Gamma, Helm, Johnson e Vlissides)
Visualização renderizada do arquivo livros/07-design-patterns-gof.md. O conteúdo abaixo é o mesmo arquivo destinado a orientar a IA.
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:
- Não force padrões onde uma solução direta é suficiente.
- Selecione pela variação que precisa ser encapsulada e pelas consequências.
- Use nomes do domínio para participantes e responsabilidades.
- Combine padrões somente quando cada um resolver uma força distinta.
- Preserve testabilidade e direção das dependências ao aplicar padrões.
Roteiro de Uso Operacional com IA
- Contextualize o projeto: informe domínio, stack, arquitetura atual, restrições e objetivo da mudança.
- Selecione o recorte: diga qual princípio/capítulo deste guia deve orientar a tarefa; não aplique tudo ao mesmo tempo.
- Peça diagnóstico antes do código: a IA deve identificar sintomas, riscos, dependências e alternativas.
- Defina critérios de aceite: comportamento, testes, acessibilidade, performance, segurança ou operação conforme o tema.
- Implemente incrementalmente: mudanças pequenas, reversíveis e verificadas.
- Faça revisão final: peça à IA que confronte a solução com este guia e liste desvios deliberados.
Prompt 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]
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
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.