Exemplo de Factory Method

Imaginem um sistema que é utilizado por uma empresa de cobrança.

Nele precisaremos estar prontos para trabalhar com diversas carteiras de cobrança, cada uma de um banco ou empresa diferente e com regras totalmente distintas entre elas, algumas promoções malucas e uma série de outros fatores.

Num cenário como esse devemos conseguir desacoplar as regras principais do negócio das regras específicas de cada carteira de cobrança, assim geramos o menor impacto possível quando cada um dos clientes da empresa mandar uma nova regra de cobrança (e podem acreditar isso é MUITO frequente).

Para simpificar o exemplo imagine que apenas a regra de calculo de juros possa variar de uma carteira para outra. Podemos nesse caso utilizar um modelo parecido com o abaixo.

Nosso sistema deverá trabalhar sempre com as classes CalculadoraCobranca e CalculadoraJuros, no entanto ireos encapsular as regras de cada banco dentro das classes concretas JurosBancoX e JurosBancoY, que serão criadas pelos seus contrutores concretos.

Ainda haerá a necessidade de alguma outra parte do sistema saber qual das classes concretas utilizar e isso certamente será resolvido pelas sua camada de aplicação, mas a regra do seu negócio fica isolada e pode ser testada e modificada muito mais facilmente do que se você utilizasse uma estrutura condicional na classe que calcula os juros.

Até a próxima.

Factories

Vou começar escrevendo aqui sobre o conjunto de Design Patterns que mais tenho visto gerar confusão, não sei se isso é verdade para todos, mas aparentemente existem alguns ilustres desconhecidos que são o tempo todo citados e nunca compreendidos.

Em primeiro lugar não há um padrão Factory (ao menos não no livro Design Patterns), eles são dois, com objetivos distintos. São eles:

Factory Method:

Abstract Factory:

Como podemos ver os modelos estruturais são bastante distintos.

A idéia é mais ou menos a seguinte:

• Com Factory Method, iremos preparar um cliente para gerar classes concretas que ele não tem conhecimento, ou seja iremos desacoplar a aplicação do conhecimento da classe concreta e deixaremos ele dependente apenas das abstrações, isso irá nos possibilitar escolher as concretizações em tempo de execução.
• Com Abstract Factory, iremos fazer com que famílias de objetos sejam sempre instânciadas juntas, evitando erros de instanciação.

Além desses dois padrões posso citar a apresentação de Padrão Factory do livro Refatoração para Padrões, onde o autor Joshua Kerievsky, chama de Factory “qualquer classe que possua um método de criação, seja estático ou não”, isso significa que tanto Factory Method quanto Abstract Factory utilizam Factorys, mas lembrem-se que nem toda Factory é um desses dois padrões.

Nos próximos posts irei detalhar mais esses padrões e colocar alguns exemplos mais palpáveis.