Bom pessoal, em mais um de nossos artigos sobre design patterns, falaremos dos padrões factory. Na verdade não existe o padrão factory, e sim padrões chamados factory method e abstract factory. Os padrões factory, tem como principal objetivo nos auxiliar a reduzir acoplamento em nosso software, ou seja, ele vai manter dependências flexiveis e para isto, fazendo com que as dependências deixem de ser explicítas, não podemos esquecer o que Uncle Bob disse: “abstração não deve depender de detalhes, detalhes é quem deve depender de abstrações” . Hoje iremos falar sobre o padrão factory method.
O por que do Factory Method
Como dito anteriormente, a meta é tornar o software mais flexivel retirando assim, as dependências explicítas. O grande problema, é que quando instânciamos diretamente um objeto, estamos criando uma dependência explicíta para o determinado objeto. Pbserve o exemplo abaixo:
var objJogador = new JogadorFutebol();
A primeira vista, pode parecer inofensivo, mais quando se trata de um software mais coplexo com uma hierarquia, por exemplo, esta simples instânciação iria estabelecer uma dependência concreta e custosa de remover; caso fosse necessário mudar de JogadorFutebol para JogadorBasquete, teriamos um problema para alterar o software. Entra em ação então o Factory Method. Em uma arquitetura, ele passa a ser o responsável por criar determinados objetos, reduzindo assim o acoplamento e até nos fazendo utilizar o princípio da responsabilidade única. Veja o diagrama do pattern abaixo:
Como visto acima, temos uma classe base abstrata( criadora ), que contém um método abstrato( factory method ) que cria um determinado objeto( produto ). Utilizando o Factory Method, você cria uma interface para os clientes utilizarem, mais deixa que eles, a responsabilidade de decir qual classe concreta instânciar. Veja o diagrama do Exemplo abaixo:

Veja o código de exemplo abaixo:

A implementação concreta:

O diagrama e os exemplos de código, ilustram claramente o padrão. Veja que a responsabilidade de instânciar o produto concreto é das classes que herdam da classe criadora, com isto temos um total desacoplamento, pois o factory method dispõe uma interface que cria um objeto, mais são as subclasses, que irão decidir qual classe concreta instânciar.
Com isso, você define a classe base que contém o factory method, as subclasses irão herdar dela, e terão a responsabilidade de decisão, sobre qual produto concreto irão instânciar; reduzindo o acoplamento e o custo de manutenção no software. No caso do exemplo, se o esportista mudar, basta apenas criar uma subclasse que crie este tipo concreto, mais a base se mantém a mesma. Veja abaixo a definição formal do padrão:
“O Factory Method define uma interface para criar um objeto, mais deixa que as subclasses decidamqula classe instânciar. O Factory Method permite a uma classe adiar a instânciação às subclasses.”
Bom Pessoal, ficamos por aqui e espero que tenha colaborado de alguma forma, para o crescimento profissional de vocês. Iremos seguir explicando os patterns, para que a opções de design de software sejam conhecidas, e você saibam quando e como utilizar para produzir um software, de melhor qualidade. Abraços e até a próxima.