Exemplo de Abstract Factory

Vamos continuar trabalhando no exemplo passado, lembrem-se do nosso sistema de cobrança.

Calcular apenas o juros não é suficiente, precisamos de muitas outras regras para chegar ao valor final que teriamos que cobrar de um devedor. Mas não podemos misturar a regra de calculo de juros de um banco com a regra de desconto do outro.

Para nos ajudar nesse tipo de situação podemos utilizar o padrão Abstract Factory. Como vimos no artigo factories ele serve para criar “famílias” de objetos. Então podemos implementar o modelo abaixo:

Nesse caso a nossa “Calculadora” conhece uma classe ques será responsável por criar todas as outras regras, e teremos que implementar uma dessas para cada banco que venha a entrar em nossa carteira de cobrança, mas não corremos o risco de alterar a regra de um banco para fazer a manutenção ou substituição da regra de outro.

Bom por enquanto é isso, e desculpem a demora na postagem.

Aceito sugestões para o próximo tema e criticas sobre o que já foi pro ar.

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.

O início

Durante os ultímos meses tenho acompanhado e participado de discussões sobre processos de software, sobre qualidade de código e modelos, sempre surgindo grandes discssões entre processos ágeis contra o RUP (sim, mudam de nome disfarçam mas espancam o pobre coitado).

Tenho visto muita coisa acontecendo e chegou minha vez de subir nesse palco e colocar minha idéias para fora.

Nesse blog tentarei colocar o máximo de informação que eu tiver sobre tudo o que envolve o bom desenvolvimento de software e espero que possamos ter discussões calorosas sobre tudo o que for colocado aqui.

Então vamos lá, vamos criar juntos uma grande força para desenvolver software com cada vez mais qualidade e cada vez mais rápido, da forma como nossos clientes gostam. :-)