Factory Method: criando objetos sem se acorrentar
O new espalhado por 14 arquivos é o sintoma; a criação concentrada é a cura. Simple factory, o método canônico, o contêiner de DI e a régua final da série de padrões.
Fechamos a série de padrões com o que decide onde os objetos nascem. Parece detalhe, até você notar o sintoma: new AdapterZentexApi(...) espalhado por 14 arquivos, cada um sabendo qual classe concreta usar e como montá-la. Quando o fornecedor muda (e ele muda), a troca vira caça ao tesouro. O Factory Method e suas variações concentram a criação num lugar só: quem usa o objeto não decide qual objeto é.
O problema e a forma mais simples da solução
// A decisão de criação espalhada (o sintoma):
const notificador =
canal === "email" ? new NotificadorEmail(smtp)
: canal === "sms" ? new NotificadorSms(zentexSdk)
: new NotificadorWhatsApp(waSdk); // ...copiado em 14 lugares
// A fábrica: a decisão mora num lugar só
class FabricaDeNotificadores {
constructor(private deps: Dependencias) {}
criar(canal: Canal): EnviadorDeNotificacoes {
switch (canal) {
case "email": return new NotificadorEmail(this.deps.smtp);
case "sms": return new NotificadorSms(this.deps.zentex);
case "whatsapp": return new NotificadorWhatsApp(this.deps.wa);
default: throw new CanalDesconhecido(canal);
}
}
}
// Quem usa só conhece a interface:
const notificador = fabrica.criar(pedido.canalPreferido);
await notificador.enviar(destino, mensagem);
Canal novo? Um lugar para mexer. Montagem complexa (credenciais, retry, adapters)? Encapsulada. E quem consome recebe a interface, nunca a classe concreta, o que destrava os testes com dublês de sempre.
As variações (e a honestidade sobre elas)
O purista notará: o exemplo acima é a Simple Factory (uma classe com switch), não o Factory Method canônico do GoF, em que subclasses decidem o que criar sobrescrevendo um método. A versão clássica brilha em frameworks: a classe base define o fluxo, e cada extensão fabrica suas peças (é assim que test runners, ORMs e UI kits deixam você plugar tipos seus). E a Abstract Factory cria famílias consistentes (todos os componentes do tema escuro; todos os fakes do ambiente de teste).
A hierarquia de uso na prática de produto, do mais para o menos frequente: simple factory ➝ factory method ➝ abstract factory. Comece simples; suba quando a variação por herança ou por família existir de verdade.
O parente rico: o contêiner de injeção
Se a fábrica organiza a criação, o contêiner de DI (NestJS, Spring, Angular) a industrializa: você declara como cada peça se constrói e quem depende de quem, e o contêiner fabrica o grafo inteiro na raiz da aplicação. Nesse mundo, muitas fábricas manuais somem, e as que sobram são exatamente as do exemplo: criação condicionada a dados de runtime (o canal do pedido, o plano do cliente), que o contêiner não conhece.
A régua final da série
Padrão criacional vale quando a variação existe: múltiplas implementações, escolha em runtime, montagem cara. FabricaDeUsuario para uma classe que só tem um jeito de nascer é a cerimônia contra a qual esta série inteira avisou. O new direto é honesto e ótimo, até a segunda implementação aparecer, e refatorar para a fábrica nesse dia é barato se as interfaces já existem.
Fechando a série: Singleton (unicidade sem globais), Decorator (comportamento em camadas), Proxy (acesso controlado), Observer (fatos e interessados), Adapter (fronteiras traduzidas) e Factory (criação concentrada). Seis ferramentas, uma régua única: padrão resolve problema recorrente; aplicado sem o problema, é o problema. É com essa régua que revisamos desenho de código no serviço de Arquitetura de Software.
Quantos new da mesma classe concreta seu domínio tem? Faça o grep e conte para a IA da Rabelo Digital, aqui no canto da tela: ela indica se pede fábrica, contêiner ou honestidade com o new. Sem formulário, sem espera.
Deixe um Comentário