Padrões Criacionais do GoF: Abstract Factory e Factory Method, entenda a diferença!

Padrões criacionais são soluções reutilizáveis para o problema de instanciar objetos. Em concurso, isso costuma cair como: “qual padrão desacopla a criação do uso?”, “qual cria famílias de objetos relacionados?”, “qual permite variar o produto sem mudar o cliente?”.

A sacada é: criação de objetos é ponto de acoplamento. Se você “nasce casado” com uma classe concreta (new ClasseConcreta()), depois sofre quando precisa trocar o comportamento, testar, simular, ou crescer o sistema.

Factory Method e Abstract Factory existem para tirar a criação do miolo da regra de negócio e colocar em um lugar controlado. Só que cada um resolve um nível diferente do problema.

O problema real: “new” demais é dor de cabeça

Imagine um sistema que gera relatórios: PDF, CSV e HTML. Se seu código está assim:

• “se for PDF, new PdfReport()”
• “se for CSV, new CsvReport()”
• “se for HTML, new HtmlReport()”

Você acabou de espalhar lógica de criação por todo canto. Toda vez que entra um formato novo, você sai caçando if/else e mexendo em um monte de arquivo.

Em termos de prova: isso fere o Open/Closed Principle (OCP): o código deveria estar aberto para extensão e fechado para modificação.

Factory Method: ideia central

Factory Method define um método de fábrica que cria o objeto, mas deixa as subclasses decidirem qual classe concreta instanciar.

Traduzindo: você programa contra uma abstração (interface/classe base) e empurra a decisão do “produto concreto” para um ponto específico.

Quando usar?

• Quando você quer variar o tipo do objeto criado sem mudar o código cliente.
• Quando você quer delegar a criação para subclasses.
• Quando o sistema vai crescer com novos tipos do mesmo “produto”.

Estrutura do Factory Method (visão de prova)

Elementos típicos:

• Product: interface/classe base do objeto criado
• ConcreteProduct: implementações concretas
• Creator: declara o factory method
• ConcreteCreator: sobrescreve o factory method para criar produtos concretos

A banca adora perguntar: “quem decide qual objeto criar?”
Resposta: as subclasses (ConcreteCreator).

Exemplo prático em Java: Factory Method

Vamos imaginar notificações (Email e SMS).

Agora, linha a linha do ponto importante:

• interface Notificacao: define o “contrato” (o cliente não depende de classe concreta).
• Notificador tem criarNotificacao() abstrato: a criação foi isolada.
• notificar() chama o factory method e usa o objeto: cliente não sabe se é Email ou SMS.
• NotificadorEmail e NotificadorSMS decidem a classe concreta: polimorfismo mandando na criação.

Uso:

Sem if/else. Sem acoplamento. Bonito e cobrável.

Abstract Factory: ideia central

Abstract Factory é o “Factory Method com esteroides” 😄. Ele cria famílias de objetos relacionados sem especificar as classes concretas.

Em vez de criar “um produto”, você cria um conjunto coerente: por exemplo:

• GUI Windows: BotaoWindows, JanelaWindows
• GUI Linux: BotaoLinux, JanelaLinux

O cliente escolhe “Windows” ou “Linux” e ganha tudo compatível, sem misturar peças.

Quando usar?

• Quando você precisa criar famílias de objetos que devem funcionar juntos.
• Quando você quer trocar o “tema”, “plataforma” ou “ambiente” do sistema facilmente.
• Quando você quer garantir consistência: não misturar produtos de famílias diferentes.

Estrutura do Abstract Factory (visão de prova)

Elementos típicos:

• AbstractFactory: interface com vários métodos de criação (um por “tipo de produto”)
• ConcreteFactory: implementa a família (WindowsFactory, LinuxFactory…)
• AbstractProducts: interfaces dos produtos (Botao, Janela…)
• ConcreteProducts: implementações por família

A banca ama a frase: “cria famílias de objetos relacionados ou dependentes”.

Exemplo prático em Java: Abstract Factory

Vamos de interface gráfica.

Cliente:

Linha a linha:

• FabricaGUI define múltiplos métodos de criação (um por produto).
• FabricaWindows e FabricaLinux garantem família consistente.
• Aplicacao depende de FabricaGUI, não de classes concretas.
• Trocar ambiente = trocar a fábrica, e o resto continua igual.

Uso:

Factory Method vs Abstract Factory: diferença que a banca cobra

• Factory Method: cria um tipo de produto, normalmente via herança (subclasses definem a criação).
• Abstract Factory: cria famílias de produtos (vários tipos relacionados), normalmente via composição (você injeta a fábrica).

Um jeito fácil de memorizar:

• Factory Method = “qual objeto eu crio?”
• Abstract Factory = “qual família de objetos eu crio?”

Pegadinhas clássicas em concurso

1. “Abstract Factory usa vários factory methods”: sim, geralmente a interface da fábrica tem vários métodos de criação (um por produto).
2. “Abstract Factory pode ser implementado usando Factory Method”: pode, e isso é comum (uma fábrica concreta implementa métodos que são factory methods).
3. “Ambos desacoplam criação do uso”: sim, mas Abstract Factory resolve o problema de consistência entre objetos relacionados.
4. “Se o problema é só escolher uma implementação simples”: Factory Method costuma ser suficiente.
5. “Se o problema é trocar plataforma/tema/fornecedor”: Abstract Factory brilha.

Onde isso aparece “na vida real” (e em prova)

• Drivers/bancos: família “Oracle” vs “Postgres” (conjuntos de objetos de acesso).
• UI: “Windows” vs “Mac” vs “Linux”.
• Serviços externos: “AWS” vs “Azure” (clientes, autenticação, storage… tudo em família).
• Testes: fábrica de objetos reais vs “fakes/mocks”.

Factory Method e Abstract Factory são padrões criacionais do GoF que te ajudam a desacoplar a criação do uso. O Factory Method delega a decisão de qual classe instanciar para subclasses, sendo ótimo quando você precisa variar um produto. Já o Abstract Factory fornece uma interface para criar famílias de objetos relacionados, garantindo consistência ao trocar “plataforma/tema/ambiente”. Dominando essa diferença, você fica muito mais rápido em prova — e com código muito mais elegante no mundo real.

Padawan, agora é mão na massa: pega uma lista de questões de GoF e tenta identificar, pelo enunciado, se a banca está falando de “produto único” (Factory Method) ou “família de produtos” (Abstract Factory). Essa distinção dá ponto fácil!Bora?

FCC – 2025 – Prefeitura de São Paulo – SP – Analista de Planejamento e Desenvolvimento Organizacional Tecnologia da Informação e Comunicação

A equipe de desenvolvimento de uma prefeitura está refatorando um sistema legado de atendimento ao público e precisa utilizar o padrão Factory Method para criar diferentes tipos de objetos relacionados a solicitações (como solicitações de manutenção, serviços ou emergências). A prática de implementação que reflete adequadamente o padrão Factory Method com foco em extensibilidade e encapsulamento é  

A) criar um método estático para instanciar objetos de solicitações com base em parâmetros fornecidos.  

B) delegar a criação de objetos para um método de inicialização dentro da própria classe principal.  

C) criar uma classe base que contenha a lógica para determinar o lipo de solicitação e retornar a instância apropriada.  

D) centralizar a criação de objetos em uma única classe utilitária que contém métodos estáticos para cada lipo de solicitação.  

E) utilizar classes abstratas ou interfaces para definir o método de criação e implementá-lo nas subclasses especificas.  

Gabarito: E

Justificativa:
A alternativa E é a que mais representa o Factory Method “raiz” do GoF, com foco em extensibilidade e encapsulamento: você define um método de criação em uma classe abstrata ou interface (Creator) e deixa as subclasses (ConcreteCreator) implementarem esse método para instanciar o produto concreto (ConcreteProduct). Assim, para adicionar um novo tipo de solicitação, você cria uma nova subclasse, sem sair alterando o código cliente (bem alinhado com o Open/Closed Principle).

Por que as outras estão erradas (estilo FCC):

• A) Errada. Método estático com parâmetros lembra mais uma Simple Factory (não é GoF) e tende a concentrar if/else/switch, reduzindo extensibilidade.
• B) Errada. Colocar a criação num método de inicialização dentro da classe principal não separa bem responsabilidades e mantém o acoplamento com as classes concretas.
• C) Errada. Uma classe base com lógica para “determinar o tipo e retornar instância” vira um centralizador (de novo cara de Simple Factory), aumentando a chance de switch crescer sem parar.
• D) Errada. “Classe utilitária com métodos estáticos” é centralização rígida e não usa polimorfismo; dificulta extensão e testes.

CESPE / CEBRASPE – 2023 – SERPRO – Analista – Especialização: Tecnologia

A respeito de padrões de projeto, julgue o próximo item.

No catálogo GoF, a classe Factory Method tem, em seu escopo, os padrões Builder, Prototype, Composite e Iterator. 

Item: FALSO.

Justificativa:
Falso porque, no catálogo GoF, Factory Method não é uma “classe” que contém outros padrões “no seu escopo”. O GoF organiza padrões por categoria (Criacionais, Estruturais, Comportamentais), e Factory Method é um padrão criacional, assim como Builder e Prototype. Já Composite é estrutural e Iterator é comportamental.

Ou seja: eles podem até ser relacionados/combinar em projetos, mas não existe essa ideia de “Factory Method ter Builder, Prototype, Composite e Iterator no escopo” no sentido de hierarquia ou “conteúdo” dentro do catálogo.

CESPE / CEBRASPE – 2025 – EMBRAPA – Analista – Área: Gestão da Informação – Subárea: Engenharia de Dados

Julgue o próximo item, relativo aos padrões de programação para smartphones, às tecnologias de persistência de dados em dispositivos móveis e aos modelos de ciclo de vida de software.

A principal característica do padrão Factory method é que ele permite a clonagem de objetos, para evitar instanciar novas instâncias repetitivamente. 

Item: FALSO.

Justificativa:
Falso porque clonagem de objetos para evitar novas instanciações repetidas é característica do padrão Prototype, não do Factory Method.

O Factory Method tem como principal ideia encapsular a criação e delegar às subclasses (ou implementações) a decisão de qual classe concreta instanciar, reduzindo acoplamento e facilitando extensibilidade — mas ele não cria objetos por clonagem.