A Fluent Paradigm For Refactoring Conditional Logic in ColdFusion

After reading this very smart piece, it became apparent that its application points to and addresses a bigger issue: complex conditional logic. When I look at code that has complex conditional logic I get a queasy feeling in the pit of my stomach, thinking about how that logic could be broken and about the complexity of the associated tests. For example, consider this example code:

function createLogin(username, password){
if( len(username) lt 8 or
len(username) gt 12 or
refind('[:punct:]', username) or
refind('[:space:]', username) or
refind('[:cntrl:]', username) ){

_throw('FormatException','Invalid Username format','Username needs to follow these rules: http://www...');

}
//Also need to do something similar for the password. Omitted for simplicity.

//After checks have passed, store credentials. Intentionally omitted.
}

You can see that this implements username requirements. The username needs to be between 8 and 12 characters, and contain only alpha-numeric characters. Yes, there are more elegant regular expressions, but this is intended to be easy to read ;-) There are some issues with this. Functionally, it may fit the specification just fine, but if something fails, how do we know which of the 5 conditions failed and what caused it to fail? Also, a developer writing a test for this code, and naturally wanting that test to cover as much as possible, would need to consider all the possible combinations. Essentially, all of the above conditions need to be false in order for the statement to be true Take a look at the following truth table which illustrates all the possible combinations needed to completely test this expression. P or Q or X or Y or Z all represent a T/F value returned by each of the conditional tests in our expression respectively: Truth table built using Truth Table Constructor What the truth table says, and what our validation also says, is that all expressions must be false in order for the if statement (the expression) to be true. If any of the conditions are true, the statement will be false and throw the FormatException. A test just for the username rule might look like this. This assumes that the createLogin method returns a boolean value. Another issue, is that all the subsequent logic after the checks will be invoked, too, which may generate unwanted side effects.

     function testCreateLogin(){
var user = createObject('component','user');
var password = 'Pa$w00rD';
var badUsernames = 'few,MoreThan12characters,hasPunc$%, ,has space,#chr(10)#,user#chr(13)#Name,user$name';
var i = 1;
var tempUser = '';
for (i; i lte listLen(badUsernames); i=i+1){
tempUser = listGetAt(badUsernames,i);
try{
 //Should fail
 actual = user.createLogin(tempUser, password);
 if(actual) {
    fail('#tempUser# passed and should not.');
 }
}
catch(usernameexception e){
      debug(tempUser);
}
}
}

Note that the above does not test all rows of the truth table; what's missing? Hint: consider row #2 of the truth table, the username should be 8-12 charcters, contain no spaces or punctuation AND contain a control character; e.g., user#char(13)#Name. That one is covered. Eek! Again we are testing the conditional logic and possibly dealing with side effects of the subsequent code. We could extract everything into a separate method, which is better. But that still leaves us with a long conditional statement, it just exists in another object. What about something like this:

function createLogin(username, password){

validator
.checkForLength(username, 'username')
.checkForSpaces(username, 'username')
.checkForPunctuation(username, 'username')
.checkForControls(username, 'username')
.validate();

//Also need to do something similar for the password. Omitted for simplicity.
//After checks have passed, create login logic. Intentionally omitted.
}

I suspect one of several responses to this: 1. What's that dot stuff? 2. Cool. Show me the code, or, maybe, you're like, 'yeah, yeah ... like, show me something new, dude'. All are welcome! :-) For those in the 1st category. That's method chaining. Check out Martin Fowler's piece on the topic. It could just as easily been written in one line:

validator.checkForLength(username, 'username').checkForSpaces(username,'username').checkForPunctuation(username,'username').checkForControls(username, 'username').validate();

Or without chaining as:

validator.checkForLength(username, 'username')
validator.checkForSpaces(username, 'username')
validator.checkForPunctuation(username, 'username')
validator.checkForControls(username, 'username')
validator.validate();

But it reads much better broken down, IMO. This has been coined "Fluency" and is useful for situations such as this; specifically, expression building. I would not recommend implementing chaining just because you can; make sure it provides some benefit. How it's done: Essentially, each validation method in the Validator object returns an instance of itself; i.e., this. This allows for the method chaining. Pretty simple, really. The Validator This is a rather simple component, as all components should be. Maybe look at it as a paradigm and write your own. You can use it out of the box to perform simple validations or tests. It has one validation method, assert(expression, source), where expression is any boolean expression and source is a name you'd like to associate with the expression. In practice, this would likely be the name of an argument or parameter or it could be used to validate a post-condition prior to a method's return statement. The only other Validator methods you need to worry about are collect() and validate(). When you exercise a validation, e.g. assert(...), and there is a failure, the Validator captures the exception information but does not throw the exception until validate() is called. This allows for multiple checks and builds details about where the failure occurred (@see 3rd paragraph). Example:

validator
.assert(1 eq 1, 'param1')
.assert(true , 'param2')
.assert( isValid('struct', {foo='bar'}), 'param3')
.validate();

Rarely are any kind of conditionals and validation like the above so simple! So, the Validator concept is intended to be extended. There are three things to know about extending it:

1. Make sure : component extends="path.to.Validator"
2. Each validation method should return THIS so chaining can be accomplished.
3. When your validation fails, call the collect(...) method in the parent; e.g., collect( 'YourFailureType', value, source);

Example:

<cfcomponent displayname="MyValidator" output="false" extends="Validator">
<cfscript>
this.MIN = createObject('java','java.lang.Integer').MIN_VALUE;
this.MAX = createObject('java','java.lang.Integer').MAX_VALUE;

function isInRange(value,src){
if( !isValid("range", value, this.MIN, this.MAX )){
collect("NumberRangeException", value, src);  }
return this;
}

function shouldtBe5AlphaCharsExactly(val,src){
if( !isValid('regex', val , '[a-zA-Z|a-zA-Z]{5,5}' ) ){
collect('StringFailureException',val,src);
}
return this;
}
</cfscript>
</cfcomponent>

Basic Usage:

function myMethod(someNumber,someId){
validator
.isInRange(someNumber,'someNumber')
.shouldtBe5AlphaCharsExactly(someId,'someId')
.validate();
//...
}

When a client calls myMethod(), the Validator is invoked and checks to see if someNumber is in the acceptable range and that someId is exactly five alpha characters long. If not, it collects the exception information and proceeds until validate() is called. validate() iterates over its exception collection and throws a general failure with details of each exception: ValidationException - One or more parameters failed validation. Parameter 'someNumber' with value '-1.2312312312312312E23' threw NumberRangeException ; Parameter 'someId' with value 'morethan5' threw StringFailureException ; There are a number of clear benefits to this:

1. The logic becomes a lot easier to test.
2. Re-use possibilities emerge.
3. Specifying the implementation of the conditional rules becomes easier.
4. The code becomes clearer to read and to maintain.
5. It may even lead to better security.

Example Tests:

<cfcomponent output="false" extends="mxunit.framework.TestCase">
<cfscript>

function outOfRangeParametersShouldFail(){
try{
validator
.isInRange(1,"param1") //ok
.isInRange(-99,"param2") //ok
.isInRange(createObject("java","java.lang.Integer").MIN_VALUE-100,"param3") //capture this
.isInRange(createObject("java","java.lang.Integer").MAX_VALUE+100,"param4") //capture this
.validate();
}
catch(ValidationException e){}
assertEquals(2, arrayLen(validator.getExceptions()),"Should be only 1 exception, because it should fail at first validate().");
}

function charLengthShouldBeOk(){
var exceptions = validator
          .shouldNotBeNoMoreThan5Chars('asdfg','param1')
          .validate()
          .getExceptions();
assertEquals(0, arrayLen(exceptions) ,'Oops. Exceptions are present in array.');
}


</cfscript>
</cfcomponent>

*Source Code Link*: http://mxunit.org/examples/validator.zip Summary: I used a parameter validation application as the example, but you can see than anywhere complex conditional logic is implemented, you could apply this. Next: This and some other things really got me thinking. Should the User object be responsible for validating? Should any object assume that responsibility? This question points to Inversion of Control and the Aspect Oriented Programming techniques of ColdSpring, Spring, and AspectJ. So, on the slate for next time will be a light-weight AOP/cross-cutting approach to this. Test and be happy ... Namasté. -bill