Rules Engines and State Machines
Sometime we find ourselves with complex sets of requirements. All too often, this results in lots of convoluted unmaintainable code. Lets start early with the concept of using a rule engine or a state machine.A good rule engine can be great when dealing with "conflicting" requirements. You can reverse the logic and show WHY something happened.
State machines really excel in event driven environments (like your J2EE app). Especially when complexity can get out of hand quickly.
Why use these. Well besides that its an established method and people might be able to understand your code...maintainability is enhanced. A new line (or modifying a line) in a state table is pretty easy. Modifying a rule (with Prolog) is much easier than diving into a rats nest of deeply nested if/elseif/else statments.
Why don't we do this more?
Update
I found a great explanation for a rules engine. The example used is highly approved by this site.
;-)
3 Comments:
I agree with you completely. Externalizing business rules is certainly a better, maintainable path towards decision automation than code, or even stored procedures.
Business Rules Technologies can seriously help in dealing with complex implementation clutter.
One of the reason i can think of why people do not use it is; they are coupled with the contemporary ways of achieving it (J2EE and regular programming stuff). May be lack of understanding the capability of state machines based rule execution can be one more....
btw, i like the name 'willCode4Beer', i'll do it as well ;)
Perhaps often it is not needed. High quality code should provide nice abstraction layers, too. So why should we use it more often at all? Since this is tightly coupled to the MDA hype, see my post about MDA.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home