Recently, I received a small demand from the company to expand the existing application rules for trial users. Our scenario might look something like this:
According to the above conditions, we can come to the conclusion that:
- Our main process is based on an and or or relationship.
- If there is a mismatch, in fact, we do not need to execute the subsequent process, that is, we need to have a short circuit function.
- For the current situation, if I change on the basis of the original, as long as a little attention to solve the problem that the demand is not very big, but said that the maintainability is very poor.
After a bit of balance, I decided to refactor this part.
Rule actuator
In view of this requirement, I first combed the general design of our rule executor, and then I designed a V1 version to share with you. If you also have such a case, you can share your comments with me. The following part is mainly about the design and implementation process and code.
Design of rule actuators
Abstraction of rules and implementation of rules
Actuator build
Call to the actuator
conclusion
The advantages and disadvantages of rule actuators
Advantages:
- Relatively simple, each rule can be independent, rules, data, the executor is split out, the caller is relatively neat;
- I define the convert method in the Rule template class to convert the parameters so that I can extend the scenario data that a particular Rule needs.
Disadvantages:
- The upper and lower rules have data dependencies. It is not reasonable to directly modify the common transport object DTO. It is recommended to build the data in advance.