Assinale O Padrão Que Utiliza Uma Fabrica De Objetos

O padrão que todo mundo implementa errado na primeira vez

A Fábrica de Objetos é um padrão criacional onde uma classe ou método centraliza a lógica de criação de instâncias, em vez de espalhar new por todo o código. Você passa os parâmetros necessários para a fábrica, e ela devolve o objeto pronto, respeitando interfaces ou contratos que você definiu. O objetivo principal é desacoplar quem precisa do objeto de quem sabe construí-lo. Na prática, isso significa que se a sua classe precisa de uma dependência que depende de configuração de banco de dados, arquivos de ambiente ou até de um serviço externo, quem consome não precisa se preocupar com isso. A fábrica resolve.

assinale o padrão que utiliza uma fabrica de objetos

Quando você vê um método cujo único propósito é receber entradas, decidir qual concrete class Instanciar e devolver uma interface, está vendo uma fábrica. Exemplo simples: um método que recebe um string com o tipo de conexão (PostgreSQL, MySQL, SQLite) e devolve uma interface IDbConnection. Quem chama nunca sabe nem precisa saber qual driver está sendo usado. O que eu recomendo é começar pela definição da interface ou classe base que seus objetos vão implementar. Se você tentar criar a fábrica antes de saber quais contratos existem, vai acabar com um monte de if-else espalhados que não agregam nada. Na minha experiência, o problema mais comum é que as pessoas transformam a fábrica em um monstro de 400 linhas com switch gigante. Isso funciona no começo, mas quando o projeto cresce, virar uma bagunça. O workaround que eu uso é dividir em fábricas especializadas por domínio. Uma fábrica para entidades de usuário, outra para configurações, outra para serializers. Cada uma com responsabilidade clara.

Um detalhe que muita gente ignora é a diferença entre Factory Method e Abstract Factory. O Factory Method é simples: uma subclasses sobrescreve um método de criação. O Abstract Factory é quando você tem famílias de objetos relacionados. Se seu sistema precisa criar conjuntos de objetos que são compatíveis entre si — como diferentes temas de UI que precisam de botões, labels e janelas que combinem —, o Abstract Factory é o caminho. Misturar os dois no mesmo lugar é uma receita para dor de cabeça. Também existe o padrão de fábrica com registradores de dependência, que é basicamente uma fábrica genérica gerenciada por um container DI. Isso é útil em aplicações grandes, mas para sistemas pequenos ou scripts rápidos, adicionar uma dependência de container inteiro pode ser overengineering. Eu já vi gente colocar Autofac ou Ninject num projeto de 200 linhas só porque "faz parte do padrão". Não faz. Aqui vai um insight contraintuitivo: em muitas linguagens modernas, a fábrica não precisa existir como uma classe separada. Você pode usar funções puras ou métodos estáticos para o mesmo efeito. O importante é a separação de responsabilidades, não a quantidade de classes no projeto. Um módulo com funções de criação bem nomeadas pode ser tão eficaz quanto uma hierarquia inteira de fábrica abstrata.

O principal problema prático que eu encontro é quando a fábrica precisa lidar com exceções durante a criação. Se um objeto depende de um arquivo que não existe, ou de uma credencial que expirou, a fábrica deve falhar de forma clara. Já perdi tempo debugando um sistema onde a fábrica retornava null silenciosamente e o consumidor dava NullReferenceException três níveis acima na pilha. Sempre lance exceções específicas com contexto suficiente. Outro ponto: fábricas que criam objetos com side effects ocultos são uma armadilha. Se a sua fábrica faz chamadas de rede, escreve no disco ou registra logs sem documentar, quem consome o objeto criado vai tersurpresas. Documente os side effects ou deixe a fábrica pura e mova as operações laterais para camadas superiores. A desvantagem real é que, em alguns casos, o padrão adiciona complexidade desnecessária. Se você tem apenas um tipo de objeto para criar, ou se a variação é mínima, introduzir uma fábrica só aumenta o boilerplate sem benefício mensurável. Para esses cenários, um construtor simples ou uma função estática fazem o mesmo trabalho com metade do código.

Quando a variação de criação realmente importa — diferentes strategies de instanciação, múltiplas famílias de objetos, dependências complexas — aí a fábrica justifica existir. E nesse caso, mantenha-a simples, testável e isolada. O resto é detalhe.