Questão de Engenharia de Software — Padrões de Projeto (Engenharia de Software) — FCC 2025

Padrões de Projeto GoF: Adapter

Gabarito: letra C. O problema descrito — integrar um módulo de pagamentos legado, com formato de dados incompatível, a um novo subsistema de cobrança online, sem modificar o código antigo — é a situação clássica que o padrão estrutural Adapter resolve: ele converte a interface de uma classe para outra interface esperada pelos clientes, permitindo que sistemas com interfaces incompatíveis trabalhem juntos. A alternativa C descreve exatamente essa intenção.

Os padrões de projeto GoF (Gang of Four) são soluções reutilizáveis para problemas recorrentes em projeto de software orientado a objetos. Eles são classificados em três famílias: criação (lidam com a criação de objetos, como Singleton e Factory Method), estruturais (tratam da composição de classes e objetos para formar estruturas maiores, como Adapter, Decorator e Composite) e comportamentais (focam na comunicação e interação entre objetos, como Observer e Strategy). O Adapter pertence à família estrutural.

O Adapter atua como um tradutor ou intermediário: ele recebe as chamadas do cliente na interface esperada e as converte para as chamadas que a classe adaptada (o sistema legado) entende. Isso é feito sem alterar o código da classe adaptada — exatamente o requisito do enunciado. Imagine um sistema novo que espera chamar um método processarPagamento(valor) em uma interface PagamentoOnline. O módulo legado, porém, expõe um método cobrar(valor, taxa, formato) com parâmetros diferentes. O Adapter implementa a interface PagamentoOnline e, internamente, traduz a chamada para cobrar(...), fazendo a conversão de dados necessária. O cliente (novo subsistema) continua usando a interface que conhece, e o legado não é tocado.

A pegadinha desta questão está em distinguir o Adapter de outros padrões estruturais que também lidam com integração, mas com propósitos diferentes. O Facade fornece uma interface unificada e simplificada para um conjunto complexo de subsistemas — ele simplifica o uso, mas não tem como foco principal a conversão de interfaces incompatíveis. O Bridge separa a abstração da implementação para que ambas possam variar independentemente. O Composite organiza objetos em estruturas hierárquicas de parte-todo. O Flyweight compartilha estado para economizar memória. O critério decisivo é: o problema é de incompatibilidade de interfaces → Adapter; o problema é de simplificar o acesso a um sistema complexo → Facade.

Guarde essa fronteira: Adapter = conversão de interface; Facade = simplificação de acesso. É exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O Facade fornece uma interface unificada e simplificada para um conjunto complexo de subsistemas, mas seu objetivo é reduzir a complexidade de uso, não converter interfaces incompatíveis. No cenário do enunciado, o problema não é a complexidade do módulo legado, mas a incompatibilidade de formatos de dados e interfaces. O Facade não resolve a conversão; ele apenas esconde a complexidade atrás de uma fachada. A banca tenta confundir o candidato apresentando o Facade como uma solução para "comunicação entre sistemas legados e novos", mas a intenção do padrão é outra.

Alternativa B — ❌ Incorreta

O Flyweight é um padrão estrutural que visa reduzir o consumo de memória compartilhando estado intrínseco entre múltiplas instâncias semelhantes. Ele não tem relação com integração de interfaces ou conversão de formatos de dados. A alternativa descreve corretamente a intenção do Flyweight, mas aplica-a a um contexto (integração entre sistemas) que não é o seu. O problema do enunciado é de incompatibilidade de interfaces, não de otimização de memória.

Alternativa C — ✅ Correta ⟵ GABARITO

O Adapter converte a interface de uma classe para outra interface esperada pelos clientes, permitindo que classes com interfaces incompatíveis trabalhem juntas. É exatamente o que o enunciado pede: o novo subsistema de cobrança online (cliente) espera uma interface específica, e o módulo de pagamentos legado tem uma interface diferente. O Adapter atua como intermediário, traduzindo as chamadas e convertendo os dados, sem modificar o código do sistema legado. A alternativa espelha com precisão a intenção do padrão.

Alternativa D — ❌ Incorreta

O Bridge separa a abstração da implementação, permitindo que ambas variem independentemente. Seu objetivo é desacoplar uma abstração de sua implementação, não converter interfaces incompatíveis. No cenário do enunciado, não há uma abstração que precise variar independentemente de sua implementação; há duas interfaces incompatíveis que precisam se comunicar. A banca usa o termo "comunicação integrada" para tentar aproximar o Bridge do problema, mas a intenção do padrão é outra.

Alternativa E — ❌ Incorreta

O Composite organiza objetos em estruturas hierárquicas de parte-todo, permitindo que clientes tratem objetos individuais e composições de objetos de forma uniforme. Ele não tem relação com integração de sistemas ou conversão de interfaces. A alternativa descreve corretamente a intenção do Composite, mas aplica-a a um contexto (comunicação entre sistemas legados e novos) que não é o seu. O problema do enunciado é de incompatibilidade de interfaces, não de hierarquia de objetos.

Gabarito: letra C