O que é factory pattern?

Factory Pattern — o que é e quando usar

O que é o Factory Pattern?

Factory Pattern (padrão de fábrica) é uma família de padrões de projeto criacionais cujo objetivo principal é encapsular a lógica de criação de objetos. Em vez de criar instâncias diretamente com um operador new espalhado pelo código, a criação é delegada a uma “fábrica” — um componente responsável por decidir qual classe concreta instanciar e como configurá-la.

Ao retirar a responsabilidade de criação do cliente, o Factory Pattern melhora o desacoplamento: clientes dependem de interfaces ou tipos abstratos, não de implementações concretas. Isso facilita trocar implementações, criar objetos com configurações diferentes ou aplicar injeção de dependência sem afetar quem consome os objetos.

Existem variações importantes: Simple Factory (não é sempre considerado um “padrão” formal), Factory Method e Abstract Factory. Todas lidam com a criação, mas diferem em como a escolha da classe concreta e a extensão do sistema são organizadas.

Principais variações (Simple Factory, Factory Method, Abstract Factory)

Simple Factory: é uma técnica onde uma classe única (a fábrica) tem um método que retorna instâncias de várias classes dependendo de um parâmetro. É simples e útil para centralizar criação, mas pode violar o princípio de responsabilidade única quando cresce.

Factory Method: define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe concreta instanciar. Ou seja, o método de criação é delegável e extensível por herança — útil quando você quer permitir que módulos estendam a criação sem modificar a fábrica base.

Abstract Factory: fornece uma interface para criar famílias relacionadas de objetos (por exemplo, UI para Windows vs. macOS). Em vez de produzir um único tipo, a fábrica abstrata cria um conjunto coerente de objetos que funcionam juntos.

Exemplos de uso práticos

Na construção de interfaces gráficas, Abstract Factory é comum: uma fábrica para “widgets” de um tema cria botões, caixas de texto e menus que combinam entre si. Assim, mudar o tema significa trocar a fábrica sem alterar o restante do código.

Em sistemas de persistência, uma Factory Method pode devolver o repositório (ou DAO) apropriado dependendo da configuração (por exemplo, SQL vs NoSQL). O cliente usa a interface do repositório sem saber qual tecnologia está por trás.

Abaixo um exemplo simples em JavaScript (Simple Factory) para ilustrar a ideia:

// Simple Factory em JavaScript
class Car { constructor(model){ this.model = model; } }
class Truck { constructor(model){ this.model = model; } }

class VehicleFactory {
static create(type, model) {
if (type === 'car') return new Car(model);
if (type === 'truck') return new Truck(model);
throw new Error('Tipo desconhecido');
}
}

const v1 = VehicleFactory.create('car', 'Sedan'); 

Benefícios do Factory Pattern

Desacoplamento: clientes dependem de abstrações (interfaces/tipos), não de classes concretas. Isso facilita testar (mock), estender e substituir implementações sem modificar o cliente.

Centralização da lógica de construção: quando criar objetos envolve passos complexos (configurações, validações, dependências), a fábrica concentra essa complexidade e reduz duplicação.

Flexibilidade e escalabilidade: novas implementações podem ser adicionadas implementando a interface e registrando-as na fábrica, ou estendendo a fábrica via herança — sem mudanças invasivas no código consumidor.

Recomendações e boas práticas ao aplicar Factory Pattern

Prefira interfaces/contratos bem definidos: defina claramente a abstração que as fábricas irão retornar. Isso garante que o cliente permaneça estável enquanto implementações mudam.

Evite fábricas monolíticas: se uma fábrica começa a ter muitas responsabilidades (muitos tipos possíveis), considere dividir em fábricas menores ou usar registro dinâmico (mapa de construtores) para manter a coesão.

Combine com injeção de dependência: em aplicações grandes, registre fábricas (ou fornecedores) no contêiner DI. Isso permite configurar a aplicação por ambiente sem alterar código e facilita testes unitários.

Recursos, links úteis e Perguntas Frequentes

Se quiser se aprofundar com exemplos e comparações, estes recursos são excelentes pontos de partida e trazem diagramas e código em várias linguagens:

• Refactoring.Guru — Factory Method (PT-BR)
• Wikipedia — Factory Method Pattern (EN)
• Microsoft Docs — Factory Pattern

Além dos links acima, vale consultar a documentação da linguagem que você usa (por exemplo, padrões em Java, C#, Python) para ver integrações com frameworks de DI e exemplos idiomáticos.

FAQ: Quando devo usar Factory Pattern ao invés de criar objetos diretamente?

Use quando a criação de objetos for complexa, quando precisar variar a classe retornada em tempo de execução, ou quando quiser desacoplar o cliente das implementações concretas. Se a criação é trivial e estável, a complexidade extra pode não valer a pena.

FAQ: Factory Pattern prejudica a performance?

Normalmente não de forma significativa. O custo de um método adicional para criar objetos é pequeno comparado aos benefícios em manutenção e flexibilidade. Em casos extremos sensíveis a performance, meça e avalie (profile) antes de otimizar prematuramente.

FAQ: Qual a diferença prática entre Factory Method e Abstract Factory?

Factory Method foca em um único produto (um tipo), delegando a subclasses a responsabilidade de escolher a implementação. Abstract Factory produz famílias de produtos relacionados (vários tipos que devem ser compatíveis entre si). Pense: Factory Method = “qual classe deste tipo eu uso?” Abstract Factory = “qual conjunto de implementações eu uso para este ambiente?”

FAQ: O Simple Factory é um padrão verdadeiro?

Simple Factory é uma expressão usada na prática para descrever uma classe que centraliza criação, mas não é formalmente parte das 23 design patterns de GoF. Ainda assim é muito útil como técnica pragmática quando usada com critérios claros.

FAQ: Posso usar Factory Pattern em linguagens funcionais?

Sim — o conceito se traduz para funções de fábrica (funções que retornam closures/objetos) ou para módulos que expõem construtores. Em FP normalmente se usa funções puras para criar estruturas imutáveis, mantendo a mesma ideia de separar criação de uso.

FAQ: E sobre testes — Factory Pattern ajuda ou atrapalha?

Ajuda: ao depender de interfaces e fábricas, você pode injetar implementações de teste (mocks/fakes) facilmente. Só tome cuidado para não ocultar muita lógica dentro da fábrica, pois isso pode tornar testes de unidade mais complexos — prefira testar a fábrica separadamente em testes de unidade.