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

Padrões de Projeto: Abstract Factory

Gabarito: letra B. O cenário exige produzir famílias de objetos relacionados (ProtocoloClient, ConsultaService, ValidadorToken) que devem ser compatíveis entre si conforme a origem dos dados, com troca dinâmica em tempo de execução e sem acoplamento a classes concretas — exatamente o propósito do padrão Abstract Factory (GoF). Esse padrão fornece uma interface para criar famílias de objetos relacionados sem especificar suas classes concretas, permitindo que o cliente use apenas interfaces e escolha a fábrica concreta em tempo de execução.

O padrão Abstract Factory é um padrão de projeto criacional que resolve o problema de criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas. A ideia central é definir uma interface de fábrica (por exemplo, IIntegracaoFactory) que declara métodos de criação para cada tipo de produto da família (por exemplo, CriarProtocoloClient(), CriarConsultaService(), CriarValidadorToken()). Cada fábrica concreta (por exemplo, SistemaAFactory, SistemaBFactory) implementa essa interface e produz um conjunto consistente de produtos — ou seja, todos os objetos criados por uma mesma fábrica são compatíveis entre si. O cliente (o módulo ASP.NET Core) depende apenas da interface IIntegracaoFactory e das interfaces dos produtos (IProtocoloClient, IConsultaService, IValidadorToken), nunca das classes concretas. Isso permite alternar dinamicamente o sistema integrado em tempo de execução: basta trocar a fábrica concreta injetada (por exemplo, via injeção de dependência ou configuração). Além disso, viabiliza testes que substituem famílias inteiras de componentes: basta criar uma fábrica de teste (mock) que implementa IIntegracaoFactory e retorna objetos falsos (fakes) para cada produto.

A razão de ser do padrão é garantir consistência entre produtos e baixo acoplamento. Sem ele, o cliente teria que instanciar diretamente as classes concretas de cada sistema, acoplando-se a elas e dificultando a troca. Com o Abstract Factory, o cliente fica isolado das implementações, e a família inteira pode ser trocada de uma só vez — exatamente o que o enunciado pede: "alternar dinamicamente o sistema integrado em tempo de execução, sem acoplamento direto às classes concretas, além de viabilizar testes que substituam famílias inteiras de componentes".

Exemplo prático: imagine que o Ministério Público integre dois sistemas externos: o Sistema X e o Sistema Y. Para cada um, há uma fábrica concreta (SistemaXFactory, SistemaYFactory) que implementa IIntegracaoFactory. O módulo principal recebe a fábrica via injeção de dependência. Se hoje o sistema ativo é o X, injeta-se SistemaXFactory; amanhã, para trocar para o Y, basta alterar a configuração para injetar SistemaYFactory — nenhuma linha do código cliente muda. Nos testes, injeta-se TesteFactory que retorna fakes. Isso é a essência do Abstract Factory.

Distinção importante: o Factory Method (alternativa C) também é um padrão criacional, mas ele cria um único produto por método, delegando a instanciação a subclasses. Ele não resolve o problema de famílias de produtos relacionados — apenas varia a implementação de um produto por herança. Já o Abstract Factory é frequentemente implementado com vários Factory Methods, mas o foco é a família.

Pegadinha da banca: a alternativa C tenta confundir o candidato ao mencionar "um único Factory Method no ProtocoloClient" — mas o Factory Method não produz famílias, e o ProtocoloClient não deveria ser responsável por criar os demais objetos (violaria a separação de responsabilidades). A alternativa D (Facade) e E (Adapter) são padrões estruturais, que lidam com a interface ou simplificação de uso, mas não com a criação de famílias. A alternativa A (Prototype) é criacional, mas foca em clonagem de objetos, não na criação de famílias consistentes.

Guarde o critério decisivo: o problema é criar famílias de objetos relacionados e compatíveis, com troca dinâmica e baixo acoplamento → Abstract Factory. É exatamente nesse critério que as alternativas se dividem.

Alternativa A — ❌ Incorreta

O Prototype é um padrão criacional que cria novos objetos clonando um protótipo existente (método Clone()). Ele é útil quando a criação é custosa ou quando se quer evitar subclasses. No cenário, não há menção a clonagem de objetos base; o problema é produzir famílias de objetos relacionados de cada sistema externo, não clonar cópias individuais. Além disso, o Prototype não garante a consistência entre os membros da família — cada clone é independente e não há uma fábrica que assegure que ProtocoloClient, ConsultaService e ValidadorToken sejam compatíveis entre si. A alternativa erra ao sugerir "clonar objetos base" e "derivar variações configuráveis" como solução para o problema de famílias.

Alternativa B — ✅ Correta ⟵ GABARITO

O Abstract Factory é exatamente o padrão para "produzir famílias de objetos relacionados (client, service, validator) de cada sistema externo, mantendo o uso apenas de interfaces e escolhendo a fábrica concreta em tempo de execução". A definição clássica do GoF: "fornece uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas". O enunciado descreve precisamente isso: cada sistema externo exige um conjunto consistente de objetos (ProtocoloClient, ConsultaService, ValidadorToken) que precisam ser compatíveis entre si conforme a origem dos dados; a equipe precisa alternar dinamicamente o sistema integrado em tempo de execução, sem acoplamento direto às classes concretas; e viabilizar testes que substituam famílias inteiras de componentes. O Abstract Factory atende a todos esses requisitos: a interface IIntegracaoFactory declara métodos de criação para cada produto; as fábricas concretas (SistemaXFactory, SistemaYFactory) produzem famílias consistentes; o cliente depende apenas de interfaces; a troca de fábrica em tempo de execução é trivial; e nos testes, uma fábrica fake substitui a família inteira.

Alternativa C — ❌ Incorreta

O Factory Method é um padrão criacional que define uma interface para criar um único objeto, deixando as subclasses decidirem qual classe instanciar. Ele não foi projetado para criar famílias de objetos relacionados — cada método de fábrica cria um produto, mas não há garantia de que os produtos criados por métodos diferentes sejam compatíveis entre si. Além disso, a alternativa sugere "criar um único Factory Method no ProtocoloClient para instanciar os objetos necessários de cada sistema" — isso colocaria a responsabilidade de criação no próprio ProtocoloClient, o que viola a separação de responsabilidades e aumenta o acoplamento. O Factory Method é útil para variar a implementação de um produto por herança, mas não resolve o problema de famílias consistentes e troca dinâmica de sistemas inteiros.

Alternativa D — ❌ Incorreta

O Facade é um padrão estrutural que fornece uma interface simplificada para um subsistema complexo. Ele não trata da criação de objetos — apenas unifica o acesso a um conjunto de classes. No cenário, o problema central é a criação de famílias de objetos relacionados e a troca dinâmica entre sistemas, não a simplificação de uma interface complexa. Embora um Facade possa ser usado em conjunto com um Abstract Factory (para expor uma interface única de uso), ele não resolve o problema de criação consistente e de alternância de famílias. A alternativa erra ao afirmar que o Facade "centraliza a criação" — isso é papel do padrão criacional, não do estrutural.

Alternativa E — ❌ Incorreta

O Adapter é um padrão estrutural que converte a interface de uma classe em outra interface esperada pelo cliente, permitindo que classes incompatíveis trabalhem juntas. Ele não trata da criação de objetos — apenas adapta interfaces existentes. A alternativa menciona "deixando a criação da família de objetos distribuída em módulos diferentes" — isso é justamente o oposto do que se deseja: a criação deve ser centralizada em uma fábrica para garantir consistência e facilitar a troca. Distribuir a criação em módulos diferentes aumentaria o acoplamento e dificultaria a substituição de famílias inteiras. O Adapter pode ser útil para padronizar a interface de cada SDK, mas não resolve o problema de criação de famílias consistentes.

Conclusão: o padrão que melhor atende ao cenário é o Abstract Factory, pois ele é o único que combina: criação de famílias de objetos relacionados, consistência entre os membros, uso de interfaces, troca dinâmica em tempo de execução e facilidade de teste com substituição de famílias inteiras.

Gabarito: letra B