email article printer friendly get the code

Stay Flexible with Logic Scripts
Take the logic scripting approach to reduce the complexity of changes and accelerate releases
by Mark Nadelson

September 2003 Issue

If you've been programming for a large corporation for more than a week, you're probably very aware that feature requirements are a moving target. There are many reasons for this situation. You might be in a business that changes like the weather, and your program must change just as quickly. Perhaps new inputs were added that didn't exist before, and now you must account for them. Maybe your users don't know exactly what they want until they use the product, realize that what they asked for was not what they meant, and don't care that such changes would have been easier to do during development. Unfortunately for you, the reason for the change doesn't really matter; it matters only that you as a developer can make it happen yesterday.

Putting a change into production, especially a change to conditional logic, is never a trivial task. The coding part is usually the easiest step. If you're lucky, the design of the system is highly encapsulated and therefore requires only a change to one or two objects. Because you know that the rest of the system remains untouched, you are confident that you need to test only the objects that have been affected. Testing these objects is of course the most difficult task. You have to ensure that you hit all paths of your conditional logic to ensure that you've achieved full code coverage. Once the changes have been coded and tested, you must release. Depending on the system, this release might require bringing down the application running on multiple users' desktops and coordinating such an effort, or it might mean taking down a 24/7 system and upgrading it. Each has a unique set of headaches.

Being involved in the ever-changing world of energy trading, I am exposed constantly to requirement changes. To expedite the time to roll out changes, I developed a set of objects that read and execute an XML script to perform logic checks within business objects. The advantage of scripting conditional logic is not having to update my code when a feature requirement has changed. I can simply update the appropriate logic script. The script-reading objects are designed so that any changes to the XML logic scripts are downloaded and implemented immediately.

Not only is the time and complexity of coding and deploying features reduced significantly, the time spent testing is also reduced. The only testing that's required is to make sure that the added or modified logic produces the correct results. A large integration test is not necessary since you have not introduced new code that could break something further downstream. Lastly, you will look like a hero if you can react to logic changes as quickly as your users modify them.

Conceal Data, Expose Methods
Before venturing into the development of the scripting XML language and the objects that do the translating, it is important to discuss the approach to take. The conditional XML language and translation objects work on the principle of object encapsulation. Object encapsulation translates to objects concealing their underlying data and exposing only methods that work on that data. Getters and setters in a well-designed object do not exist because they expose too much of the underlying data.