O problema
Uma aplicação pode oferecer armazenamento local para desenvolvimento e armazenamento em nuvem para produção. Misturar um cliente de nuvem com um repositório local pode gerar uma combinação inválida. Abstract Factory declara operações para criar uma família de produtos relacionados; cada fábrica concreta produz um conjunto coerente.
Exemplo em C#
public interface IRepositorioPedido { }
public interface IArmazenamentoArquivo { }
public interface IInfraFactory
{
IRepositorioPedido CriarRepositorioPedido();
IArmazenamentoArquivo CriarArmazenamentoArquivo();
}
public sealed class LocalInfraFactory : IInfraFactory
{
public IRepositorioPedido CriarRepositorioPedido() => new SqlitePedidoRepository();
public IArmazenamentoArquivo CriarArmazenamentoArquivo() => new PastaLocal();
}
public sealed class CloudInfraFactory : IInfraFactory
{
public IRepositorioPedido CriarRepositorioPedido() => new PostgresPedidoRepository();
public IArmazenamentoArquivo CriarArmazenamentoArquivo() => new BlobStorage();
}A configuração escolhe uma fábrica uma vez; os consumidores recebem produtos compatíveis. Em aplicações com DI, registros tipados por ambiente podem cumprir esse papel sem exigir que cada classe consulte uma fábrica global.
Benefícios e custo
O padrão protege a consistência entre produtos e esconde detalhes de criação. O custo é que adicionar um novo tipo de produto pode exigir alterar todas as fábricas. Ele faz sentido quando famílias variam juntas e a matriz de combinações precisa ser controlada; é exagero para objetos independentes ou uma única implementação estável.
Padrões relacionados
Factory Method costuma criar um produto, enquanto Abstract Factory coordena vários produtos relacionados. Builder foca em montar um objeto complexo. Explore o catálogo completo GoF e Clean Architecture para posicionar fábricas na composição da aplicação.