Dicionário de TI de A a Z

O que é factory method?

Factory Method — a explicação perfeita sobre o que é

Factory Method é um padrão de projeto da categoria “creational” (criação) que define uma interface para criar um objeto, mas deixa que subclasses decidam qual classe concreta será instanciada. Em vez de chamar diretamente um construtor (por exemplo, usando new), o código chama um método especial — o “factory method” — que encapsula o processo de criação do objeto, promovendo baixo acoplamento e maior flexibilidade. :contentReference[oaicite:0]{index=0}

O padrão surge da necessidade de separar a responsabilidade de criação de objetos do seu uso, permitindo que o sistema adicione novos tipos concretos sem modificar o código cliente. Essa separação facilita a manutenção, a extensão e até os testes unitários (já que o código criador pode ser substituído ou mockado). :contentReference[oaicite:1]{index=1}

Curiosidade: embora exista uma família de padrões relacionados (como Abstract Factory e Simple Factory), o Factory Method é um dos 23 padrões clássicos descritos pelo “Gang of Four” e é especialmente útil quando você quer delegar a escolha da classe concreta a subclasses. :contentReference[oaicite:2]{index=2}

O que é (detalhando a ideia e a estrutura)

Na prática, o Factory Method define um método abstrato (ou virtual) em uma classe “criadora” (Creator). Essa classe usa o produto retornado por esse método, mas não conhece sua implementação concreta — quem decide qual produto criar é a subclasse concreta do Creator. Isso promove a abertura para extensão e o fechamento para alteração (Open/Closed Principle).

Estruturalmente, há normalmente três participantes: o Creator (declara o factory method), os ConcreteCreators (implementam o factory method) e os Products/ConcreteProducts (o que é criado). O Creator pode fornecer uma implementação padrão do método que pode ser sobrescrita. Esse arranjo costuma ser representado em UML em diagramas simples que mostram a delegação da criação. :contentReference[oaicite:3]{index=3}

Uma variante comum é usar factory methods estáticos (em linguagens que suportam), transformando o padrão em algo parecido com “alternative constructors” — nomes descritivos para formas alternativas de construir instâncias. Isso ajuda a evitar construtores confusos e sobrecarregados. :contentReference[oaicite:4]{index=4}

Curiosidade: em linguagens dinâmicas (ex: Python), a linha entre construtor e factory pode ficar borrada — funções que retornam objetos (factory functions) cumprem papel semelhante ao Factory Method sem precisar de classes abstratas.

Exemplos de uso (quando e onde aplicar)

Um cenário clássico é um framework que precisa criar componentes que podem ser estendidos pelo cliente: por exemplo, um jogo que cria diferentes tipos de salas (MagicRoom, OrdinaryRoom) dependendo do modo. O framework chama o factory method e cada implementação concreta produz a versão apropriada. :contentReference[oaicite:5]{index=5}

Em aplicações empresariais, é comum ver Factory Method em sistemas de persistência/DAO onde uma camada superior não sabe se a persistência será feita via MySQL, PostgreSQL ou um serviço remoto; cada ConcreteCreator retorna um DAO adequado. Também aparece em SDKs de UI onde lib cria widgets específicos conforme plataforma ou tema.

Outro uso prático: integração com provedores (provider pattern). Ex.: ADO.NET usa conceitos de factory para permitir código independente do provedor (SqlClient, Oracle, Odbc). Assim, o mesmo código de acesso pode trabalhar com provedores diferentes, sem mudanças no cliente. :contentReference[oaicite:6]{index=6}

Benefícios do Factory Method

Maior desacoplamento entre cliente e classes concretas: o cliente depende de abstrações (interfaces/abstract classes) enquanto a decisão de criação fica encapsulada. Isso simplifica mudanças e adiciona extensibilidade, pois novas classes podem ser introduzidas sem alterar o cliente. :contentReference[oaicite:7]{index=7}

Facilita testes e injeção de dependência: como o ponto de criação é centralizado, fica mais fácil substituir implementações por mocks em testes. Também combina bem com contêineres de DI (Dependency Injection), onde factories ajudam a controlar ciclo de vida e configuração de objetos. :contentReference[oaicite:8]{index=8}

Permite nomes descritivos e construção controlada: factory methods podem ter nomes que descrevem a intenção (ex.: FromCsv, FromConfig), tornando o código mais legível e ajudando a evitar múltiplos construtores ambíguos. Além disso, lógica complexa de inicialização pode ficar dentro da fábrica. :contentReference[oaicite:9]{index=9}

Recomendações e boas práticas

Use Factory Method quando a criação do objeto exige lógica que pode variar (por exemplo, escolher subtipos) ou quando a criação precisa ser isolada para facilitar mudanças futuras. Evite introduzir factories desnecessárias apenas por hábito; se o código nunca mudará e não há ganho em abstração, o padrão adiciona complexidade.

Combine com Dependency Injection e interfaces claras: exponha interfaces para os produtos e injete factories (ou use providers) quando possível. Isso mantém o código testável. Em linguagens modernas, considere também a possibilidade de usar funções ou expressões lambda como fábricas simples antes de partir para uma hierarquia de classes. :contentReference[oaicite:10]{index=10}

Documente as responsabilidades: defina claramente quem é responsável por configurar o objeto (fábrica) e quem é responsável por usá-lo (cliente). Se a fábrica faz muita coisa além de criar (ex.: registrar, configurar, conectar), talvez valha a pena dividir responsabilidades (Single Responsibility Principle). :contentReference[oaicite:11]{index=11}

Links e leituras recomendadas

Para aprofundar, recomendo estas referências técnicas que explicam conceito, variações e exemplos práticos:

Refactoring.Guru — Factory Method — ótima explicação com UML, exemplos e refatorações. :contentReference[oaicite:12]{index=12}
Wikipedia — Factory method pattern — histórico, definição e citações do GoF. :contentReference[oaicite:13]{index=13}
Microsoft Docs / Visual Studio Toolbox — Design Patterns: Factories — exemplos aplicados ao ecossistema .NET e diferenças entre Abstract Factory e Factory Method. :contentReference[oaicite:14]{index=14}

Curiosidade técnica: além do Factory Method clássico, existem variantes como Simple Factory (não é um padrão GoF formal), Factory Function (em linguagens funcionais) e Abstract Factory (para famílias de produtos). Saber diferenciar essas abordagens evita confusão arquitetural.

Dúvidas frequentes (FAQ)

O Factory Method é a mesma coisa que Abstract Factory?

Não. Factory Method define um método para criar um único tipo de produto e delega a escolha da subclasse para as subclasses do Creator. Abstract Factory encapsula a criação de famílias de objetos relacionados (vários produtos que devem funcionar juntos). Use Abstract Factory quando precisar garantir compatibilidade entre vários produtos. :contentReference[oaicite:15]{index=15}

Quando eu devo preferir uma função fábrica simples em vez do padrão com classes?

Se sua linguagem é dinâmica ou funcional (ex.: JavaScript, Python), e a criação não requer herança complexa, uma factory function ou factory estática pode ser mais simples e suficiente. Prefira classes/factory methods quando precisar de polimorfismo por herança ou quando a hierarquia for parte do domínio. :contentReference[oaicite:16]{index=16}

Factory Method aumenta a complexidade do código?

Sim, pode aumentar a quantidade de classes e arquivos. Por isso, aplique-o quando os benefícios (extensibilidade, desacoplamento, testes) superarem o custo de manutenção. Evite padrões “por purismo”: cada padrão deve resolver um problema real. :contentReference[oaicite:17]{index=17}

É seguro usar Factory Method em aplicações com alto desempenho em tempo de execução?

Normalmente sim — o overhead de chamar um método adicional é mínimo comparado ao custo do objeto criado. Se a criação de objetos for extremamente frequente e crítica, considere cache, pooling ou técnicas de otimização (ex.: object pool) em conjunto com a factory para reduzir alocações. :contentReference[oaicite:18]{index=18}

Existe algum exemplo minimalista de código (pseudo) para entender a ideia?

Sim — aqui vai um exemplo simples em pseudocódigo que ilustra a essência:

// Creator
abstract class DocumentCreator {
  abstract createDocument(): Document;
  openDocument(): void {
    doc = this.createDocument();
    doc.open();
  }
}

// ConcreteCreator
class PdfCreator extends DocumentCreator {
createDocument(): Document { return new PdfDocument(); }
}

// Product
interface Document { open(): void; }

// ConcreteProduct
class PdfDocument implements Document {
open(): void { /* abrir PDF */ }
}

Nesse exemplo, o cliente chama openDocument() e a subclasse decide qual Document concreto será criado.

Se quiser, posso transformar esse artigo em uma versão pronta para publicação com marcações para blog (meta tags, resumo, autor) ou gerar exemplos em uma linguagem específica (Java, C#, TypeScript, Python) — diga qual você prefere e eu adapto imediatamente.

::contentReference[oaicite:19]{index=19}