Reputation: 753
Currently, we are using JEXL expression evaluator in our microservice. However, we would like to have the flexibility to change this to some other expression evaluator in future. The issue here is that the expression evaluators from different vendors do not inherit methods from a common interface. Thus, different expression evaluators could have different methods as well as different method signatures, although under the hood they do provide similar functionality. How can I approach this problem in a way that avoids changing the entire code base in case we do decide to change the expression evaluator in future ? It would be helpful if the answer includes a sample code implementing this scenario.
Upvotes: 0
Views: 113
Reputation: 59233
Well, @Admx mentions the adapter pattern in comments, and normally in situations like this that would be a good idea. It boils down to three steps:
Write an interface that defined what you need an expression evaluator to do;
Implement that interface using JEXL
Encapsulate creation of evaluators in a factory so that you can swap implementations whenever you want.
In this case, there is a problem with that idea: The expression language is part of the interface.
It's quite unlikely that any other 3rd party expression evaluator is going to implement the same expression language. That means that if you swap out JEXL for something else, then you'll have to edit all the expressions you need it to evaluate.
Is that really a direction you expect you project to evolve in? Probably not.
Since you can't really use JEXL without tying your product to JEXL, you might just want to incorporate JEXL source into your own code base, and maintain it from there as if it was your own. It's Apache-licensed and not too big, so that is certainly doable. You don't need to do this now, but it's an option you can turn to if JEXL ends up causing you trouble.
Upvotes: 1