Strategy pode caber em duas funções

Strategy organiza alternativas de um comportamento que o contexto utiliza por um contrato comum. Aqui, a alternativa é representar o retrato como CSV ou PDF. Uma tabela que associa o nome do formato a uma função pode cumprir esse papel. O fluxo escolhe uma função, fornece os registros e recebe conteúdo e tipo de mídia.

Não precisamos começar com uma classe abstrata e uma fábrica. Se as funções são pequenas, uma seleção explícita com dois ramos pode ser mais clara. O custo começa a mudar quando cada representação ganha configuração própria, dependências distintas ou manutenção independente. Nesse caso, receber um objeto exportador pode tornar a colaboração mais legível.

A seleção continua existindo em algum lugar, normalmente na montagem da operação. O ganho é concentrá-la e evitar que formato determine autorização, consulta e entrega por caminhos diferentes. Acrescentar uma alternativa não significa que nenhum arquivo existente será editado; o ponto de registro pode precisar mudar.

Composição não é proibir toda herança

Na conversa de Erich Gamma sobre princípios de design, ele relaciona interfaces à gestão de dependências e discute a preferência por composição sobre herança. A colaboração precisa permitir variar a implementação sem prender o cliente a detalhes desnecessários.

No exercício, o serviço de relatórios recebe o exportador escolhido. Ele não herda de CsvReport nem de PdfReport. Essa composição permite trocar a representação sem redefinir o fluxo. Se a biblioteca de PDF exige subclasses para algum ponto de extensão, avalie essa exigência no adaptador, preservando uma fronteira compreensível para o restante da aplicação.

Também evite interpretar interface como uma obrigação de criar o recurso interface de uma linguagem. Uma função com contrato explícito pode bastar. O que precisa permanecer estável é a colaboração prometida ao cliente, inclusive erros e efeitos externos, não apenas a lista de métodos.

Adapter trata outra diferença

Imagine que o fornecedor de PDF exige HTML e devolve um identificador de tarefa, enquanto a aplicação espera conteúdo pronto. Um Adapter pode traduzir essa interface para a esperada pelo relatório. Ele monta a entrada, acompanha o resultado conforme o contrato do fornecedor e transforma falhas em resultados compreensíveis para o chamador.

Isso é diferente da escolha entre CSV e PDF. Strategy representa alternativas de formato; Adapter resolve incompatibilidade com a interface de um participante. A mesma solução pode usar as duas ideias, mas elas respondem a perguntas distintas. Trocar o fornecedor de PDF deveria afetar a tradução, sem alterar a seleção de registros autorizados.

Se o fornecedor só termina de forma assíncrona, fingir que tudo é uma chamada instantânea cria expectativas falsas. O contrato pode precisar de prazo máximo ou de um estado de relatório em preparação. O nome Adapter não elimina esse custo nem torna equivalentes tempos e modos de falha diferentes.

Por que Observer não faz falta neste caso

O fluxo descrito tem um solicitante esperando um resultado. Não há requisito para vários interessados serem notificados sobre mudanças do relatório. Uma chamada explícita organiza a sequência de obter dados, representar e responder sem acrescentar assinaturas de eventos e regras de inscrição.

Observer faria sentido diante de uma necessidade de notificação entre um sujeito e seus observadores. Adicioná-lo apenas porque a exportação tem várias etapas cria perguntas novas: quem se inscreve, quando sai, em qual ordem é chamado e o que acontece se falha? Essas respostas precisam de um requisito que justifique sua manutenção.

Um broker distribuído também não se torna automaticamente uma implementação equivalente de Observer. Persistência, entrega repetida e independência de processos acrescentam outro conjunto de decisões. O catálogo ajuda a nomear uma relação de responsabilidades, sem fornecer sozinho um contrato operacional de mensageria.

O que verificar antes de declarar melhoria

Use os dois registros para comparar a solução atual com a proposta. Confirme o CSV exato, o conteúdo semântico do PDF e a preservação da ordem. Verifique que cada solicitação faz a seleção de dados uma única vez e que o exportador não amplia o acesso concedido ao usuário.

Depois acrescente uma representação de texto simples: A-1: 1500 BRL cents e A-2: 2500 BRL cents, nessa ordem. Observe se a alteração toca a autorização ou apenas implementação e registro da nova representação. O texto é outra expectativa didática, não um novo artefato produzido pela resenha.

Conte também o trabalho de leitura. Se antes era necessário entender um método e agora é preciso navegar por oito arquivos para encontrar o cabeçalho, procure a vantagem que paga esse custo. Uma abstração melhora o projeto quando facilita uma mudança relevante sem esconder decisões importantes.

O que envelheceu e onde a recomendação tem limites

O contexto de C++ e Smalltalk não deve ser transformado em exigência de copiar estruturas em linguagens diferentes. Funções de primeira classe podem substituir parte de uma hierarquia usada para variar comportamento. Isso não elimina a questão de design, mas pode reduzir a quantidade de mecanismo necessária para respondê-la.

Na entrevista retrospectiva, os autores reconhecem que algumas linguagens oferecem formas alternativas para problemas do catálogo. Portanto, evite aprender uma solução e procurar lugares para implantá-la. Considere primeiro o suporte já presente na linguagem, na biblioteca de renderização ou no framework.

Também não trate uma colaboração local como solução completa para produção. O exercício não demonstra exportação de grandes volumes, cancelamento, acessibilidade do PDF ou compatibilidade com leitores. Se o CSV passará a aceitar texto arbitrário, defina escaping e interpretação pelo consumidor. São contratos do produto, que a escolha de Strategy não resolve.

Para quem recomendo e quais livros complementam

Recomendo para quem já entende objetos, polimorfismo e dependências e consegue relacionar um exemplo a código que mantém. Um iniciante sem essa base pode decorar nomes sem reconhecer os problemas. Nesse caso, implemente primeiro duas versões simples do exportador e observe onde a mudança se espalha.

Refactoring, de Fowler, ajuda a caminhar de uma estrutura existente para outra, preservando comportamento. A Philosophy of Software Design, de Ousterhout, oferece uma lente sobre a complexidade que as interfaces escondem ou espalham. Clean Code complementa a discussão de legibilidade local.

O catálogo merece prioridade quando você precisa reconhecer colaborações em uma biblioteca ou justificar uma variação recorrente. Para um script curto com dois formatos estáveis, a solução simples pode durar bastante. Compreender um padrão inclui saber por que sua implementação completa seria excessiva ali.

Plano de leitura e veredito

Escolha um ponto de mudança que já exista. Leia a intenção de dois candidatos, examine suas consequências e escreva a alternativa sem padrão explícito. Só depois compare estruturas e exemplos. Registre o que varia, quem escolhe a alternativa e quais garantias o cliente precisa conservar.

Faça uma mudança pequena e peça a outra pessoa que acompanhe uma chamada até o resultado. Se ela consegue explicar a colaboração e o custo introduzido, o vocabulário está ajudando. Se depende de reconhecer siglas para aceitar o desenho, volte ao problema original.

Recomendo Design Patterns como catálogo de decisões reutilizáveis. Sua contribuição aparece quando um nome encurta uma conversa precisa sobre responsabilidades e consequências. A meta é entender a variação e pagar apenas pela flexibilidade necessária ao código que você realmente tem.