}
// If single hit, exit after first condition match
if (rule.singlehit){
exit=true
}
}
}
}
}
}
In Listing 22-10, first the RuleEngineImpl implements the RuleEngine Java interface, and Spring's
annotation is applied like any other POJO. Within the run() method, the parameters defined in the rule
were passed into a closure for processing one by one. For each parameter (which is a list of values), the
conditions (each condition is a closure) are checked one by one with the corresponding item within the
parameter's list and the domain object. The success indicator becomes true only when all the conditions
result in a positive match. In this case, the actions (each action is a closure too) defined in the rule will be
performed on the object, with the corresponding value within the parameter's list. Finally, if a match is
found for a specific parameter and the singlehit variable is true, the rule execution will be stopped and
will exit immediately.
To allow the retrieval of a rule in a more flexible way, let's define a RuleFactory interface, as shown
in Listing 22-11. Note that it's a Java interface.
Listing 22-11. The RuleFactory Interface
package com.apress.prospring3.ch22.rule.factory;
import com.apress.prospring3.ch22.rule.domain.Rule;
public interface RuleFactory {
public Rule getAgeCategoryRule();
}
In Listing 22-11, since there is only one rule for an age category classification for contacts, the
interface defines only a single method for retrieving the rule.
To make our rule engine transparent to the consumer, let's develop a simple service layer to wrap it
up. Listing 22-12 and Listing 22-13 show the ContactService interface and the ContactServiceImpl class,
respectively. Note that they are Java implementations.
Listing 22-12. The ContactService Interface
package com.apress.prospring3.ch22.service;
import com.apress.prospring3.ch22.domain.Contact;
public interface ContactService {
public void applyRule(Contact contact);
}
Search WWH :
