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!!
Que tal utilizar linguagens de script? Groovy é uma boa pedida…
?? Mas nesse caso meu as regras vão ficar no lado servidor.
A Paz!!
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…
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. 
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
[quote=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…
[/quote]
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!
[quote=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. [/quote]
Mas eu teria que parar a aplicação para mudar os scripts?!
A Paz!!
[quote=paulohbmetal][quote=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. [/quote]
Mas eu teria que parar a aplicação para mudar os scripts?!
A Paz!![/quote]
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.
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.
