O problema que todo mundo subestima quando começa a usar Abstract Factory
Eu já vi várias equipes implementarem esse padrão em sistemas de venda e, na maioria das vezes, eles acabam criando uma fábrica que é mais complexa do que o problema que ela deveria resolver. Acontece que você não precisa de Abstract Factory para tudo. Ele tem um propósito muito específico e quando você tenta usá-lo como solução universal, o código vira um queijo suíço cheio de interfaces aninhadas. O padrão Abstract Factory existe para criar famílias de objetos relacionados sem que o código cliente dependa das classes concretas. Em um sistema de vendas online, isso se traduz em algo como: você tem produtos físicos e produtos digitais, cada um com métodos de cálculo de frete, cálculo de impostos e validação de estoque diferentes. A fábrica abstrata garante que, ao instanciar um produto, você receba todos os objetos correlatos já compatíveis entre si.
em um sistema de vendas online o padrão abstract factory
Vamos direto ao ponto prático. Suponha que seu sistema tenha três tipos de produto: eletrônico, vestuário e serviço digital. Cada um precisa de um calculador de imposto, um validador de estoque e um gerador de nota fiscal. Sem o padrão, você teria classes concretas espalhadas por toda a base de código com condicionais if-else ou switch gigantescas. Com Abstract Factory, você define uma interface para a família de fábricas e depois cria uma implementação concreta por tipo de produto.
interface ProdutoFactory {
CalculadorImposto criarCalculadorImposto();
ValidadorEstoque criarValidadorEstoque();
NotaFiscalGenerator criarNotaFiscal();
}
class FactoryEletronico implements ProdutoFactory {
public CalculadorImposto criarCalculadorImposto() {
return new IpiCalculador();
}
public ValidadorEstoque criarValidadorEstoque() {
return new EstoqueFisicoValidador();
}
public NotaFiscalGenerator criarNotaFiscal() {
return new NfEletronicoGenerator();
}
}Isso parece simples, mas existe uma armadilha que poucos mencionam. Se você adicionar um novo método à interface da fábrica abstrata, precisa atualizar todas as implementações concretas, mesmo aquelas que não precisam daquele novo comportamento. Isso quebra o principio Aberta-Fechada na prática, porque você está modificando código existente para adicionar funcionalidade nova. Na minha experiência, a solução mais limpa é usar default methods em interfaces Java a partir da versão 8, ou então aceitar que a fábrica terá alguns métodos que retornam null ou um valor padrão para famílias que não fazem sentido naquele contexto. Não é bonito, mas é honesto e evita refatorações em cascata toda vez que o produto muda.
Quando o padrão funciona bem e quando ele destrói seu projeto
Abstract Factory se encaixa perfeitamente em sistemas de vendas online onde os produtos têm configurações e regras de negócio claramente segmentadas por categoria. Aqui estão exemplos práticos: Cenário 1: múltiplos gateways de pagamento por tipo de produto. Eletrônicos podem exigir pagamento parcelado com verificação de CPF, enquanto serviços digitais aceitam apenas pagamento à vista. A fábrica abstrata garante que o gateway correto seja instanciado junto com o validador de documento e o simulador de parcelas, tudo como um par consistente.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Cenário 2: regras fiscais por região e tipo de produto. Um sistema de vendas que atende múltiplos estados brasileiros precisa calcular ICMS de formas diferentes dependendo do produto e da UF do destinatário. A fábrica abstrata permite que você crie famílias de calculadoras fiscais por estado, sem espalhar lógica condicional pelo código todo. O problema real surge quando você tem apenas dois ou três tipos de produto com diferenças mínimas. Nesse caso, o overhead de criar interfaces, classes abstratas e implementações consome mais tempo do que vale a pena. Eu vi uma equipe gastar três dias implementando quatro fábricas abstratas para um sistema que na verdade só precisava de uma simple factory com alguns parâmetros de configuração. O resultado foi um projeto com 47 classes extras que ninguém conseguia entender direito.
Um problema real que eu enfrentei e como resolvi
Em um projeto de e-commerce, nós precisávamos adicionar um novo tipo de produto: assinaturas recorrentes. O problema era que o validador de estoque não fazia sentido para assinaturas. A interface da fábrica abstrata exigia que retornássemos um ValidadorEstoque, mas a lógica era completamente diferente. Precisávamos validar período de vigência, quantidade de vagas e limite de renovação. A solução que eu adotei foi criar uma sub-interface específica para o validador de assinaturas e tratar isso como um caso especial na factory concrete. Na prática, eu devolvia null para o validador genérico de estoque nas assinaturas e o código cliente verificava se o objeto era nulo antes de usar. Funcionou, mas custou duas semanas de ajustes porque o times de QA tinha que testar cada cenário de null pointer em produção.
A lição que eu levei disso: se os filhos de uma família não são realmente coesos, talvez Abstract Factory não seja o padrão certo. Nesse caso, Strategy ou uma combinação de Factory Method com Builder faria muito mais sentido.
Alternativas que vale considerar
Se você tem um sistema de vendas online com produtos que variam mais por atributos do que por famílias completas, considere usar o padrão Builder em vez de Abstract Factory. Ele permite construir objetos passo a passo sem a rigidez de famílias inteiras. Outra alternativa é composição pura: ter uma classe Produto com injeção de dependência dos comportamentos específicos, usando interfaces simples e não fábricas aninhadas. Abstract Factory também não escala bem para sistemas que precisam adicionar novos tipos de produto com frequência. Cada novo tipo exige uma nova implementação de fábrica, o que aumenta o custo de manutenção linearmente. Se seu domínio exige essa flexibilidade, um sistema baseado em regras ou plugins pode ser mais adequado do que um padrão estrutural fixo.
O ponto final é que Abstract Factory em um sistema de vendas online é uma ferramenta válida, mas não é a resposta para todos os problemas de criação de objetos. Use quando você tiver famílias claramente definidas de produtos com comportamentos correlatos. Não use quando as diferenças forem pontuais ou quando o domínio evoluir rapidamente. E nunca implemente sem primeiro mapear todas as famílias de produtos que existem hoje e projetar para as que provavelmente existirão no futuro próximo.
