O problema com Abstract Factories
Bem, quem nunca enfrentou um problema onde você tem uma abstração definida e algumas implementações dessas abstrações que já estão funcionando, mas o tempo passa e mais classes concretas vão sendo criadas em cima dessa abstração e chega um momento que tudo vira um inferno e você não aguenta mais fazer type checking e if pra instanciar a classe que você quer.
CALMA! existe solução(será?)
Existe um cara que pode te ajudar, é tranquilo, só chamar e ele resolve seu problema!
Ele se chama Abstract Factory!
Então você vai lá, entra no Google, descobre como que implementa, e pode ser que na hora do build mesmo você já enfrente sérios problemas!
Uma Factory Abstrata esconde toda parte concreta do cliente e dentro das suas implementações, ela também se baseia em adivinha o que? ABSTRAÇÕES, então se em algum ponto, alguma das classes concretas precisar de algo fora do que a sua Interface diz que ela tem, o uso desse pattern já não é tão válido.
Ficou muito abstrato? (HAHA, ENTENDEU ESSA PIADA? NÃO? DEVE SER PORQUE VOCÊ NÃO SABE COMO QUE EU IMPLEMENTEI ELA)
Aqui vão alguns exemplos
Digamos que nós precisamos desenhar um sistema de compras, e a compra pode ser feita presencial ou pela internet, e pela internet a pessoa precisa falar qual seu endereço para que seja feita a entrega.
Então vamos lá:
Suas implementações:
Nossa Interface da Factory:
Implementações da Factory:
Agora vou querer rodar e ver se está tudo certo, quero um comprador online pra poder fazer uma compra:
Como da pra ver, erro no build, ficou tudo vermelho.
Eu mandei a implementação certa, porque ele não acha o método??
Lembra lá em cima quando eu expliquei que Factories Abstratas se baseiam em Abstrações, esse é o porque, na nossa abstração de IComprador não temos nenhum método relacionado a Informar dados ou CPF.
Isso pode ser resolvido de uma maneira simples, que é essa aqui:
Mockei alguns dados na CompradorOnlineFactory só para caso de estudo, eles poderiam vir de qualquer lugar:
E:
EEEEEE:
Olha, talvez essa não tenha sido a melhor das soluções, por mais que ela não desrespeite totalmente o Open/Closed Principle, ela limita esse príncipio, porque nossa abstração agora só aceita dois parâmetros string, sendo que em uma das implementações o cliente precisa saber detalhes sobre a classe concreta de CompradorOnline para não ter uma exceção.
Existem outros Patterns que podem servir melhor em casos de implementações muito especificas, nos acompanhe para saber sempre que abordarmos um novo assunto :)
