4 ms·
Ask HN: Would you implement a decision table library, in 2015?
I would really appreciate the HN's community advice on this topic.
My requirement is to take decisions based on a common mechanism, not a workflow but merely a matching approach via a decision table (the concept has been pushed as a solution since the beginning, refusing rule engines and wishing to get rid of if-else code). The proposed solution is a decision table, with decision conditions (a column) and actions (another column) + some operators (boolean, any, not, business-like) in order to have a reusable library, matching a set of decisions based on a provided decision table and a matching function, semantically free, via decision table definition in XML, decision table manageable in memory, dynamic SQL creation.
However, I do not really support this solution as I think performances, scalability and clustering (if in-memory-table would be used) would be seriously impacted. And the library would then end up as not-so-reusable and force its consumers to workarounds/adaptations/steps-back. Moreover, I see several principles which could be easily broken: KISS (Keep it Stupid Simple), YAGNI (You Ain't Gonna Need It), somehow also PLA (Principle of Least Astonishment). Too many buzz words perhaps, but the alternative would probably be to use an existing product (OpenL Tablets, DTRules, JBoos Drools) or rethink the solution just via Design patterns appliances (if you really don't want to see if-else everywhere).
Would you really implement a decision table library in 2015? Would you actually use decision tables in your application or push for other alternatives?
Thanks a lot!
- canterburry 12y agoWhy don't you just use drools decision tables? http://docs.jboss.org/drools/release/5.3.0.Final/drools-expert-docs/html/ch06.html http://docs.jboss.org/drools/release/5.3.0.Final/drools-expe...
- pjungwir 12y agoIf this is to cut down on if-else code then I'd say it depends on how many if-elses you're saving. More often I see people take this approach to let end users compose rules for various actions. But this kind of thing tends to be what I call a "Turing complete" feature, where people are always writing rules that go beyond what your model can express. ("If there are two of these, and one is not older than this, and their mean is greater than the most recent of these, and the current time is before 8 a.m. in the time zone of the user who owns this user's account . . .") In that case, if your users are sophisticated enough (e.g. internal users in a "services" division of your company), you might want to consider going with embedded Javascript instead. You can expose a few objects/functions from your application and let people write JS using them. Then you run their JS and see if it evaluates to true. I've used this in a Ruby context before with the gem therubyracer. This is nice because your app gets a full-featured scripting language for free. You don't have to design the language or write an interpreter. Javascript is designed to be very secure. It can't do IO or run shell commands. And it's probably the most widely-understood programming language out there, so there's a low learning curve. Challenges are that your users have to understand a programming language, and you'll probably want to take steps to validate the Javascript they're writing and to surface decent error messages when problems happen. Also therubyracer can use a lot of memory, which may or may not be a concern depending. Another challenge is that the JS will be opaque to an outside computer system. It's hard to break it down and express what it's all about. For instance you couldn't run a query to find all actions that require condition foo. Good luck!
- davismwfl 12y agoRules engines are awesome and are super powerful, but add a layer of complexity that is not inconsequential. I have implemented a lot of rules engines, and removed a fair number of them too since the late 90's. I generally removed them because they created a dependency nightmare, added crazy complexity and required significant extra test conditions that the application just didn't need to have. This can slow your development down considerably for smaller applications and cause great frustration. Which is not what a rules engine should do. My basic starting thoughts is that if the rules are well known, change infrequently, have minimal nested chaining and number < 50 or so then I'd opt for having a good design pattern or simple if/else within the code. If you violate any of these tenants, then I'd look at decision tables/trees first, then after that move to a rules engine. Of course, if users are required to write their own then that would also have to factor in to this decision. BTW -- Don't dismiss a good design pattern or even a plug-in pattern as sometimes that is more than enough to solve moderately complex rules without adding additional dependencies or significant development complexity. If this is an application that will be deployed to third party sites, then again, I generally opt for a balance between the number of dependencies and the application maintenance. If it is deployed behind a website or application where your company controls the environment, then I focus more on flexibility and application maintenance than dependencies. Also, in a few less common scenario's, I have written very basic purpose built rules engines that solved some of the key issues without creating needless complexity, maintenance or dependency nightmares. Not that I advocate writing libraries/code that already exists, but many times you just don't need a Drools, or ilog rules etc. Also, this is where something like embedded JavaScript is a handy tool as pjungwir also mentioned.