A medida que pasa el tiempo, en el desarrollo de aplicaciones de software, muchas cosas cambian, el equipo de trabajo cambia, las fechas de entrega y también los requerimientos iniciales ya sea porque el usuario final no sabia que quería o porque el funcional no entendio nada o simplemente por el hecho de que todo cambia (evoluciona).
Dada esta necesidad de cambio (casi constante) en los requerimientos de una aplicación se hace necesario hacer que el software que construimos sea flexible y fácil de modificar.
Como se dijo en el
post anterior, OT-Rules permite escribir ciertas validaciones (o lógica de negocio) en una forma flexible, donde agregar nuevas reglas, modificar y eliminar reglas existentes y cambiar el comportamiento de como se debe ejecutar estas reglas se hace muy facil y simple.
Aquí utilizaremos el código de ejemplo utilizado para el post anterior y por supuesto, agregaremos algunas cositas.
Categorización de reglas.OT-Rules contiene una categorización de las reglas que este provee:
* Reglas de soporte: Son aquellas que facilitan el desarrollo por ejemplo (
net.sf.opentranquera.rules.support.TrueRule o
net.sf.opentranquera.rules.support.FalseRule).
* Reglas lógicas: Ejecutan acciones lógicas como AND, OR, XOR, NOT.
* Reglas condicionales: Ejecutan condiciones, hasta ahora solo
net.sf.opentranquera.rules.conditional.IfRule.
* Reglas iterativas: Reglas que iteran e invoquan a otras reglas (FOR, WHILE)
Short circuitTodas las reglas lógicas tienen el atributo
short circuit que debería ser setteado en la creación/construcción de la regla, el cual permite definir el modo de ejecución que tendra ésta y trabaja de la misma manera que lo hace el
short circuit de la clausula if de Java.
Veamoslo en un ejemplo usando un AND:
a && b -> short circuit = true: Si "a" se evalua en false (con lo cual el AND daria false independientemente de lo que "b") no se evalua el resultado de "b".
a & b -> short circuit = false: Si "a" se evalua en false (con lo cual el AND daria false independientemente de lo que "b") igualmente se evalua el resultado de "b".
Es decir, si tengo una regla de tipo AND que esta compuesta por otras tres reglas, como se puede ver en la regla llamada "transferRule" (del ejemplo anterior), solo se evaluara en
true si todas se evaluan en
true individualmente.
<bean id="transferRule" class="net.sf.opentranquera.rules.logical.AndRule">
<constructor-arg index="0">
<list>
<bean class="net.sf.opentranquera.samples.rules.DifferentAccountRule"/>
<bean class="net.sf.opentranquera.samples.rules.AccountsExistsRule">
<property name="rule" ref="accountExistsRule"/>
</bean>
</list>
</constructor-arg>
<constructor-arg index="1" value="true"/>
</bean>
El primer argumento del constructor es un List de Rules y el segundo argumento es un boolean que índica si la regla es short circuit (por defecto "short circuit = true").
Ahora bien, si "DifferentAccountRule = true", se evalua AccountsExistsRule, si esta es true, entonces la evaluación de la regla transferRule sera
true. Pero sí "DifferentAccountRule = false", AccountsExistsRule no sera evaluada (ejecutada) y el resultado sera
false.
De la misma forma que lo hacemos con la regla AND, lo podemos hacer con las reglas OR, XOR.
Entonces, podemos finalizar diciendo que en el caso de que sea necesario cambiar este tipo de comportamiento de una regla lógica simplemente se modifica el valor del atributo short circuit en la configuración (sea cual sea), es así de fácil.
La regla NOT.Existe una regla lógica que permite negar el resultado de la evaluación de otro regla (
net.sf.opentranquera.rules.logical.NotRule).
Esta regla se crea a partír de otra y la envuelve (se podría decír que la decora utilizando el pattern Decorator), luego al evaluarla (llamar a su método evaluate()) se evalua la regla contenida para finalmente negar su resultado (manteniendo todos sus mensajes).
Veamos algunos ejemplos:
Usando el XML de configuración de OR-Rules:
<rule name="test.not.rule" ruleClass="net.sf.opentranquera.rules.logical.NotRule">
<rule ruleClass="net.sf.opentranquera.rules.support.FalseRule"/>
</rule>
Creo una NotRule incluyendo una FalseRule. El resultado de esto es la negación de la evaluación de FalseRule (que siempre da false), es decir me devuelve el resultado
true.
<rule name="test.negate.rule" ruleClass="net.sf.opentranquera.rules.support.FalseRule"
modifier="negate"/>
Aquí, se utiliza el atributo "modifier", esto indica que la rule "test.negate.rule" que es del tipo FalseRule debe ser negada luego de ejecutar. Es decír, el resultado sera
true.
Ahora veremos esta mismo configuración usando SpringFramework:
<bean id="transferRule" class="net.sf.opentranquera.rules.logical.NotRule">
<constructor-arg index="0">
<bean class="net.sf.opentranquera.rules.support.FalseRule"/>
</constructor-arg>
</bean>
Simple no?
Cambiar lógica de evaluación.Llamo lógica de evaluación a aquella que no concierne a la regla en si, sino a como esta se evalua o a como se ejecutan las diferentes reglas que contiene, por ejemplo, si utilizo un regla AND para componer la ejecución de varias reglas, digo que la lógica del AND (ya sea con short circuit o no) es mi lógica de evaluación, mientras que las reglas ejecutan la lógica de negocio/validación que quiero evaluar.
OT-Rules provee varias clases (reglas) que me permiten modificar esta lógica de evaluación independientemente de lo que hacen las reglas en sí mismas, de forma tal que los programadores se concentren en resolver la problematica particular de negocio y luego las componen utilizando alguna clase de OT-Rules (o alguna creada por ellos dado que OT-Rules es flexible en este aspecto) para decidir como van a ser evaluadas y ejecutadas.
Ahora bien, si en lugar de tener las reglas escritar con OT-Rules las tendrias escritas directamente sobre el código del método del servicio y tendriamos la necesidad de modificar la forma en que se evaluan las reglas y no las reglas en sí. Esto seria muy problematico, dado que tendriamos que modificar gran parte de nuestro código ya testeado.
Pero si tenemos las reglas separadas en clases (incluso con sus test unitarios) para luego decirles por configuración como se evaluan, podría no ser tan problematico. De hecho, utilizando OT-Rules sería muy simple. En el caso recien mencionado, simplemente tendriamos que cambiar la AND rule por la nueva forma de evalución requerida (OR, XOR, etc).
En el ejemplo anterior utilizabamos una AND rule para armar la regla "transferRule", pero si ahora necesitaramos que la evaluacion de esta rule esta basada en una lógica de OR, simplemente cambiamos la clase
ANDRule, por la
ORRule quedando de la siguiente manera:
<bean id="transferRule" class="net.sf.opentranquera.rules.logical.OrRule">
<constructor-arg index="0">
<list>
<bean class="net.sf.opentranquera.samples.rules.DifferentAccountRule"/>
<bean class="net.sf.opentranquera.samples.rules.AccountsExistsRule">
<property name="rule" ref="accountExistsRule"/>
</bean>
</list>
</constructor-arg>
<constructor-arg index="1" value="true"/>
</bean>
La de misma forma que cambiamos un AND por un OR podemos, incluso, componer reglas lógicas, por ejemplo, dentro de una regla OR tener un regla NOT que contiene una regla AND que a su vez contiene otras reglas (que pueden ser reglas de negocio o reglas compuestas AND, OR, XOR, etc.).
Reuso de reglas (otra vez).Veamos lo recien comentado con un ejemplo.
Recordemos del articulo anterior que teniamos la regla "transferRule" que evaluaba que al realizar una transferencia, las cuentas sean distintas, que existan y que la cuenta débito tenga el dinero disponible para realizarla.
Ahora agregaremos un nuevo método para el servicio TransferService que realice una transferencia pero entre un mismo banco a modo de ejemplo. Para este caso es válida la regla (compuesta) "transferRule" y ádemas agregaremos la siguiente lógica de validación:
# Como dijimos debe pasar la regla transferRule con lo cual estariamos haciendo reuso de la misma.
# Verificar que la transferencia tenga como cuenta débito y cuenta crédito el mismo banco o bancos del mismo grupo empresarial.
Veamos ahora como queda el nuevo método y la configuración de OT-Rules
public boolean bankTransfer(Transfer transfer) throws TransferException {
this.evaluator.setEvaluatedObject(transfer);
RuleResult result = this.evaluator.evaluateRule("bankTransfer");
if(!result.isSuccessful())
throw new TransferException(result.getMessages());
// TODO logic ...
return true;
}
<bean id="bankTransferRule" class="net.sf.opentranquera.rules.logical.AndRule">
<constructor-arg index="0">
<list>
<ref local="transferRule"/>
<bean class="net.sf.opentranquera.rules.logical.OrRule">
<constructor-arg index="0">
<list>
<bean class="net.sf.opentranquera.samples.rules.SameBankRule"/>
<bean class="net.sf.opentranquera.samples.rules.SameBankGroupRule"/>
</list>
</constructor-arg>
<constructor-arg index="1" value="true"/>
</bean>
</list>
</constructor-arg>
<constructor-arg index="1" value="false"/>
</bean>
Como podemos ver la nueva regla (bankTransferRule) tiene una lógica de evaluación del tipo AND que contiene la ya creada y declarada "transferRule" junto con una nueva regla del tipo
OR que a su vez se compone de otras dos reglas, una que verifica que las cuentas sean del mismo banco y la otra que las cuentas sean del mismo grupo empresarial.
Al evaluarse esta regla se dispararían las siguientes acciones:
# Se evalua "transferRule", es decir se evalua la regla AND junto con sus compuestos.
# Si la regla anterior da true, se evalua la regla OR. Esta regla compuesta ejecuta SameBankRule y SameBankGroupRule, si alguna de ellas da true, esta regla devuelve un resultado en true.
# Finalmente si ambas reglas se evaluaron en true, se retorna un resultado true.
Nota: Se podria hacer echo toda esta valiadcion en una sola regla (o de otras multiples formas utilizando diferentes tipos de composiciones), sin embargo lo hice asà a modo de ejemplo.Usar fluent interface como mecanismo de configuración.OT-Rules tiene dos mecanismo de configuración por código:
1) Creando las clases directamente utilizando el operador new: Como lo hacen los test case
XorRule xorRule = new XorRule();
xorRule.addRule(new FalseRule());
xorRule.addRule(new TrueRule());
xorRule.evaluate();
2) Utilzando al API fluida: Evita la necesidad de conocer las clases, es mas declarativa e intuitiva
FluentRule fir = new FluentRule("test");
fir.rule(new FalseRule()).xor(new TrueRule()).or(new FalseRule()).not();
RuleEvaluator evaluator = FluentInterfaceRuleEvaluatorBuilder.createRuleEvaluator(fir);
RuleResult result = evaluator.evaluateRule("test");
Más allá de que podemos reemplazar toda la configuración del ejemplo anterior usando esta API, para este tutorial solamente reemplazaremos la regla "transferRule" y para ello haremos uso del componente de OTF llamado bridge (OT-Bridge sirve para integrar las frameworks de OTF con otras frameworks).
No modificaremos nada de código, todo es configuración (en realidad agregaremos una clase que tiene la codificación usando la API fluida).
La declaración de la regla en el rulesContext.xml queda asi:
<bean id="transferRule" class="net.sf.opentranquera.spring.rules.FluentRuleInterfaceFactoryBean">
<property name="config">
<bean class="net.sf.opentranquera.samples.rules.FluentConfigImpl"/>
</property>
</bean>
Usando el FactoryBean
FluentRuleInterfaceFactoryBean podemos configurar una rule usando la API fluida. En la propiedad "config" se inyecta la clase que implemente de
net.sf.opentranquera.spring.rules.FluentConfig que contiene la codificación/configuración permitente.
public class FluentConfigImpl implements FluentConfig, BeanFactoryAware {
private BeanFactory bf;
public FluentRule getFluent() {
// create the rules
DifferentAccountRule diffAccount = new DifferentAccountRule();
AccountsExistsRule accountExists = new AccountsExistsRule();
DebitAccountRule debitAccount = new DebitAccountRule();
// get object from Spring
AccountExistsRule accountExist = (AccountExistsRule)this.bf.getBean("accountExistsRule");
accountExists.setRule(accountExist);
FluentRule rule = new FluentRule("transferRule");
rule.rule(diffAccount).and(accountExists).and(debitAccount);
return rule;
}
public void setBeanFactory(BeanFactory bf) throws BeansException {
this.bf = bf;
}
}
Ahora, cuando se pide evaluar a la regla "transferRule" esta se obtendra ahora desde la configuración de la API fluida (y gracias los mecanismos internos de OT-Rules y OT-Bridge) permitiendo que sea transparente a la configuracion de la aplicacion.
Conclusión.Hemos visto mas en detalle aspectos particulares de OT-Rules, como ser la categorización de reglas que propone y la regla NOT, como asi tambien el uso del atributo short circuit. Aprendimos que es la lógica de evaluación de una regla (según OT-Rules). Por ultimo conocimos como configurar el engine utilizando directamente código, mas presisamente con el uso de una API fluida.
