Lots of Patterns

Boa noite galera,
vou explicar o problema que tenho pra depois colocar minhas duvidas:

Estou trabalhando numa aplicação que gere contratos dos clientes, é muito parecido como quando vc compra um celular pré pago e vai consumindo os créditos mensais que vc adquiriu em determinado plano, porém os ‘créditos’ nesta app são relatórios financeiros de alguma empresa.
A maioria dos clientes sao bancos que fazem emprestimos e querem saber a instabilidade da empresa que esta a pedir dinheiro.

  • Um Contrato pertence a 1 Cliente

  • Um Contrato pode ter varios Serviços ( cada serviço fornece relatorios com diferentes tipos de informaçao)

  • Cada Serviço tem uma quantidade de créditos, ex: 1 crédito == 1 relatório ( mas depende do tipo de requisicao)

  • Cada Serviço pode ter 1 Bonus. Ex: se o cliente consumir 50% dos creditos daqele serviço irá ganhar 20% do total de créditos que contratou.

  • O cliente pode escolher na hora do consumo se quer pagar em Dinheiro ou debitar créditos, se for em dinheiro é gerada uma linha de fatura que no fim do mes chega ao cliente por correio. ( pagar em dinheiro é necessario pois ha clientes estrangeiros que nao querem comprar creditos que talvez nao vao usar)

  • Os clientes irão consumir os créditos através de uma chamada a um WebService, passando todos os parametros necessários para a geração do relatorio (login e senha, empresa desejada, prioridade de entrega, Serviço que deseja retirar os créditos, modo de pagamento etc).

  • A cada requisição:

[list]Autorizar pelo login e senha[/list]
[list]Consultar os Saldos e ver se pode consumir naquele Serviço, senao procura outro Serviço ou retorna dizendo que o saldo zerou[/list]
[list]Criar um Movimento que persiste as infos desse consumo e debitar do saldo do Serviço[/list]
[list]Se o cliente pediu o mesmo relatorio a menos de 2 dias, debita do saldo esse consumo, porém faz um Movimento de crédito que deixará o saldo igual antes do consumo, isso seria uma Duplicata[/list]
[list]Se for pagamento a Dinheiro, criar a Linha de Fatura e o movimento associado[/list]
[list]Se o consumo for suficiente pra gerar Bonus, entao gera um movimento de Bonus que credita o serviço de acordo[/list]
[list]Ainda podem haver: cancelamento de consumos e varios outros tipos de consumo que irao servir um sistema legado em VB.[/list]

[list]No fim de tudo o retorno deve conter uma lista com cada ação tomada (a Response)[/list]

Como vcs podem ver existem, varios passos que dependem um do outro para acontecerem ou não.
Outra grande agravante é que sao varias ações a serem tomadas em diferentes entidades.
E a pior agravante que eu vejo é que cada ação tem que dar feedback pra que a proxima possa ocorrer

Eu poderia desenvolver isso com uma classe ConsumoManager que tem um metodo gigante chamado consumir(DadosRequisicao req), o qual faria toda a logica (if e elses ¬¬ ) e que geraria os movimentos, debitos, duplicatas, anulacoes, faturas etc.

Mas bah Java é orientado a objetos e eu sei q se fizer isso a primeira manutencao que alguem fizer, vai querer me cortar a garganta :0, pois trocentos principios OO foram estuprados e a cada mudança TODO o codigo terá q ser testado.

Portanto, eu estou em busca de um Design Pattern(meio bala de prata essa…) ou a combinação de alguns DPs para que o codigo fique facil de manter e adicionar novas features no futuro.

Sou iniciante nesse mundo dos Patterns, mas ja estudei sobre Strategy, Decorator, Chain Of Responsabilities, Factory, Command e Mediator, Template Method( que pelo visto nao eh muito recomendado por causa da herança).

Mas estou meio perdido, pois nenhum deles consegue me livrar de ter uma classe que terá que instrumentar o processo todo, digamos o ConsumoManager, ou seja, ainda nao consigo me livrar dos if-elses pra todo lado, consigo diminui-los (e muito) utilizando Strategy , Factory e Command.

Eu tentei o CoR, mas fica estranho pois isso nao é um processo ‘cego’ que cada handler pode fazer sem se importar com o todo.

O grande problema é que eu nao encontro um padrao que direcione todo o fluxo da coisa.

Gostaria de qualquer idéia ou ajuda de voces que ja passaram por algo parecido.

Eu até colocaria algum codigo aqui, mas eh muita coisa e ninguem gosta de ler mais de 20 linhas de codigo num post, nem eu :^)

Muito obrigado

Junico

Se você não sabe aplicar Patterns, não os aplique. A pior coisa que você pode fazer é ter uma solução na mão e criar um problema não existia antes para ela resolver. E é o que acaba acontecendo.

Desenhe as tuas classes da melhor maneira que lhe convir, e deixe os patterns de lado por enquanto. Eles nunca foram receitas de bolo para fazer algo funcionar, eles são somente padrões que acontecem. Mantendo um bom design, uma hora algum vai surgir no teu projeto, e você vai pensar “estava usando um pattern e nem sabia”. Na próxima vez você vai lembrar dele.

Não quer dizer que você não vá ler nada sobre eles, leia sim, mas para saber que existem e para entender melhor no futuro.

Muito Obrigado pela resposta Bruno.

Vou seguir seu conselho.

A minha duvida sobre ter um cara que coordena o feedback de cada ação e decide a próxima, parece me que nao é um problema no fim.
Afinal alguém tem que fazer isso.
Porém, como vc falou, desenhando as classes sem descuidar nos principios OO, eu consigo fazer esse Manager apenas ‘gerenciar’ as coisas, sem se importar ‘como’ elas sao feitas, (Design by Contract).

Abraços e até a proxima

Só tome cuidado na hora de fazer esse gerenciador, caso precise mesmo, para não cair prática de ficar passando dados de um lado para outro, separando eles de seus próprios comportamentos, o que deixaria de ser OO.