Padrões de projeto - Negócio "plugável"

24 de julho de 2006 9 respostas

paulohbmetal 24 de julho de 2006

E aí galera, blz? Seguinte, foi me solicitado em um projeto, que as regras de negócio de uma aplicação poderão ser desabilitadas sem alteração em código. A solução que surgiu foi cadastrar as mesmas no banco, relacionando a classe que executa a mesma na aplicação. Daí via reflection eu instanciaria as mesmas no momento da necessidade. O que pergunto é: existe algum padrão de projeto que me ajude com isso? Pensei no command, mas essas minhas classes deverão receber parâmetros, o que me parece fugir um pouco do command.

E aí?

A Paz!!

9 Respostas

TriTonE 24 de jul. de 2006

Que tal utilizar linguagens de script? Groovy é uma boa pedida…

paulohbmetal 24 de jul. de 2006

?? Mas nesse caso meu as regras vão ficar no lado servidor.

A Paz!!

rodrigoy 24 de jul. de 2006

Fala Paulo… aí diversos padrões podem ser adotados. Foque em padrões de comportamento.

Da maneira que você descreveu, logo de cara vejo a aplicação do pattern Strategy. Com ele você pode definir comportamentos (regras de negócio) em runtime, deixando os comportamentos encapsulados em classes.

Exemplo:

public class PedidoVenda {
   
   private long numero;
   private String nomeCliente;

   private FaturarBehavior faturarBehavior;

   public PedidoVenda(numero, nomeCliente) {
      //TODO: implement me
   }

   //outras operações get, set e e de negócio

   public void faturar() {
      faturarBehavior.faturar();
   }

}

public interface FaturarBehavior {
   public void faturar();
}

public class MeuFaturamento implements FaturarBehavior {

   public void faturar() {
      //TODO: meu faturar específico
   }

}

Esse é só um exemplo. Para definir que o MeuFaturamento vai ser usado você pode usar um Factory de Pedido ou Dependency Injection.

Você também pode usar Decorator para mudar comportamentos em runtime. Existem outros patterns. Uma literatura boa é o Head First Design Patterns em inglês. A didática é espetacular e a cobertura do assunto para JAVA é muito bom…

TriTonE 24 de jul. de 2006

Bom… qual é o problema que as regras estão do lado do servidor? Você pode simplesmente modificar regras de negócio alterando ou trocando o script.

Sei lá, na minha opinião é bem menos porco do que guardar os nomes das classes no banco e chamá-las via reflection.

TriTonE 24 de jul. de 2006

Bom… tá aí minha sugestão…

Dê uma olhada no “Quick Start” do Groovy e veja se ela se adapta ao que você deseja fazer.

http://groovy.codehaus.org/Quick+Start

paulohbmetal 24 de jul. de 2006

rodrigoy:
Fala Paulo… aí diversos padrões podem ser adotados. Foque em padrões de comportamento.

Da maneira que você descreveu, logo de cara vejo a aplicação do pattern Strategy. Com ele você pode definir comportamentos (regras de negócio) em runtime, deixando os comportamentos encapsulados em classes.

Exemplo:
public class PedidoVenda {
   
   private long numero;
   private String nomeCliente;

   private FaturarBehavior faturarBehavior;

   public PedidoVenda(numero, nomeCliente) {
      //TODO: implement me
   }

   //outras operações get, set e e de negócio

   public void faturar() {
      faturarBehavior.faturar();
   }

}

public interface FaturarBehavior {
   public void faturar();
}

public class MeuFaturamento implements FaturarBehavior {

   public void faturar() {
      //TODO: meu faturar específico
   }

}
Esse é só um exemplo. Para definir que o MeuFaturamento vai ser usado você pode usar um Factory de Pedido ou Dependency Injection.

Você também pode usar Decorator para mudar comportamentos em runtime. Existem outros patterns. Uma literatura boa é o Head First Design Patterns em inglês. A didática é espetacular e a cobertura do assunto para JAVA é muito bom…

Cara, vc quase que acerta até o domínio do problema. O software que estou projetando/desenvolvendo é um Workflow de Pedidos. Tais pedidos devem passar por aprovação em várias gerencias e cada gerência tem suas regras de negócio específicas.
Daí minha idéia é relacionar tais regras de negócio às gerencias e aplicá-las no fluxo(por isso a idéia de cadastrar). Dái o que iria fazer seria criar uma interface que todas as classes de regras de negócio(pedido) iriam implementa-las. Daí quando necessário, eu obteria as mesmas através de Factory(que buscaria no banco e instanciaria por reflection).

O que acham desta abordagem?

Valeu!

A Paz!

paulohbmetal 24 de jul. de 2006

TriTonE:
Bom… qual é o problema que as regras estão do lado do servidor? Você pode simplesmente modificar regras de negócio alterando ou trocando o script.

Sei lá, na minha opinião é bem menos porco do que guardar os nomes das classes no banco e chamá-las via reflection.

Mas eu teria que parar a aplicação para mudar os scripts?!

A Paz!!

TriTonE 24 de jul. de 2006

paulohbmetal:
TriTonE:
Bom… qual é o problema que as regras estão do lado do servidor? Você pode simplesmente modificar regras de negócio alterando ou trocando o script.

Sei lá, na minha opinião é bem menos porco do que guardar os nomes das classes no banco e chamá-las via reflection.

Mas eu teria que parar a aplicação para mudar os scripts?!

A Paz!!

Considerando que os scripts são interpretados, basta que você substitua o arquivo no servidor. Não sei te informar com certeza, mas acho que você consegue fazer deploy dos scripts através de hot-deploy. Como os scripts são interpretados, assim que você colocar o script no servidor, a nova regra já estará sendo aplicada nas próximas requisições.

juzepeleteiro 24 de jul. de 2006

Regras de negocios? Utilize uma Rule Engine.

Duas que eu conheço e assino embaixo: JBoss Rules (antigo Drools) e o da iLog.

O da iLog é mais completo com todo o workflow e ferramental já pronto, mas custa caro. O JBoss Rules você vai ter que desenvolver repositorio, workflow (de aprovação) e etc, mas é de grátis e mui boa.

Procure por Rules Engine no tio Google que tem mas.

Criado 24 de julho de 2006

Ultima resposta 24 de jul. de 2006

Respostas 9

Participantes 4

9 Respostas

Topicos relacionados