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

Padrão de Projeto Factory Method

Gabarito: letra B. O Factory Method é corretamente implementado quando se define um método de criação abstrato (em uma classe abstrata ou interface) e se delega a cada subclasse concreta a decisão de qual objeto instanciar — é exatamente o que a alternativa B descreve. Essa estrutura promove extensibilidade (novos tipos de solicitação entram criando novas subclasses, sem alterar o código cliente) e encapsulamento (o cliente conhece apenas a interface do produto, não a classe concreta).

O Factory Method é um dos padrões de projeto criacionais do catálogo GoF (Gang of Four). Ele resolve um problema clássico: quando uma classe precisa criar objetos, mas não sabe de antemão qual classe concreta instanciar — ou quer deixar essa decisão para as subclasses. Em vez de a classe principal usar new diretamente (o que a acoplaria a uma implementação específica), ela declara um método abstrato de criação (o factory method) e as subclasses o implementam, cada uma retornando o produto que lhe cabe.

Vamos ao exemplo do enunciado: uma prefeitura tem solicitações de manutenção, serviços e emergências. Sem o padrão, o código cliente faria algo como if (tipo == "manutencao") return new SolicitacaoManutencao(); else if (tipo == "servico") return new SolicitacaoServico(); ... — um emaranhado de condicionais que cresce a cada novo tipo e viola o princípio do Open/Closed (aberto para extensão, fechado para modificação). Com o Factory Method, você define uma interface CriadorSolicitacao com o método criarSolicitacao(), e cada subclasse — CriadorManutencao, CriadorServico, CriadorEmergencia — implementa esse método retornando o objeto correto. O cliente chama o método abstrato e recebe o produto sem saber qual classe concreta foi instanciada.

A distinção que mais confunde em provas é entre Factory Method e Abstract Factory. O Factory Method usa herança: a criação é feita por um método que as subclasses sobrescrevem. O Abstract Factory usa composição: uma fábrica (objeto) é responsável por criar famílias de produtos relacionados, sem que o cliente saiba qual fábrica concreta está usando. Outro vizinho é o Simple Factory (ou Factory estática), que não é um padrão GoF: é apenas uma classe utilitária com um método estático que decide qual objeto criar — exatamente o que as alternativas A e C descrevem, e que não é o Factory Method.

A pegadinha da banca aqui é justamente confundir Factory Method com essas abordagens mais simples (fábrica estática/centralizada) ou com uma variação que concentra a lógica de decisão em um único lugar. O Factory Method não centraliza a criação em uma classe utilitária; ele a distribui entre as subclasses, cada uma criando o seu produto. É essa descentralização que garante a extensibilidade: para adicionar um novo tipo de solicitação, você cria uma nova subclasse do criador — não altera código existente.

Guarde o critério decisivo: o Factory Method exige herança e sobrescrita de um método de criação abstrato. Se a alternativa fala em "método estático", "classe utilitária", "lógica centralizada" ou "método de inicialização na própria classe", ela está descrevendo outra coisa — provavelmente uma fábrica simples ou uma abordagem acoplada. É exatamente nesse critério que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Centralizar a criação em uma classe utilitária com métodos estáticos é a descrição do Simple Factory (ou Factory estática), que não é o padrão Factory Method do GoF. O Factory Method não usa métodos estáticos nem uma classe central: ele usa polimorfismo por herança, com o método de criação sendo abstrato e implementado nas subclasses. Além disso, uma classe utilitária centralizada viola o Open/Closed — cada novo tipo de solicitação exigiria alterar essa classe, em vez de apenas adicionar uma nova subclasse.

Alternativa B — ✅ Correta ⟵ GABARITO

Esta é a definição canônica do Factory Method: definir uma interface ou classe abstrata com o método de criação (o factory method) e implementá-lo nas subclasses concretas. Cada subclasse decide qual produto instanciar, encapsulando a lógica de criação e permitindo estender o sistema com novos tipos de solicitação sem modificar o código existente — exatamente o que o enunciado pede (extensibilidade e encapsulamento). O cliente depende apenas da abstração, não das classes concretas.

Alternativa C — ❌ Incorreta

Criar um método estático que instancia objetos com base em parâmetros é, novamente, a descrição do Simple Factory (ou fábrica estática). O Factory Method não é estático e não recebe parâmetros para decidir o tipo — a decisão é tomada pela subclasse que implementa o método. Um método estático com switch/if centraliza a lógica e acopla o criador a todas as implementações, o que contraria o espírito do padrão.

Alternativa D — ❌ Incorreta

Delegar a criação para um método de inicialização dentro da própria classe principal não é Factory Method. Isso descreve uma abordagem em que a própria classe (que deveria ser o creator abstrato) contém a lógica de criação — o que a acopla às implementações concretas e impede a extensão por subclasses. No Factory Method, o método de criação é abstrato e a lógica de qual objeto criar fica nas subclasses, não na classe principal.

Alternativa E — ❌ Incorreta

Criar uma classe base que contenha a lógica para determinar o tipo e retornar a instância apropriada é uma descrição genérica que se aproxima mais de uma fábrica simples ou de um método fábrica com condicionais — não do Factory Method. O padrão exige que a decisão de qual produto criar seja delegada às subclasses (via sobrescrita do método abstrato), e não que a classe base concentre a lógica de decisão. Se a classe base decide o tipo, não há polimorfismo de criação — e a extensibilidade fica comprometida.

Gabarito: letra B