Wednesday, March 7, 2012

The Architectural IF

"IF" is one of the fundamental constructs of programming languages. (Yes, I know someone will know at least 3 languages without "IF", but I know a lot more which have "IF").

"IF", like a Biro is so ubiquitous that it's pretty much impossible to imagine life without it.

But as the Biro has been superseded by the Computer for works of any length, "IF" has been superseded in many ways by better ways of doing things.

If makes a nice living dealing with details. But often we can avoid it by simple design

 var myClientList = GetClientList();  
   
 if (myClientList != null)  
 {  
   sendAnnoyingEmailsTo(myClientList);  
 }  

What if GetClientList() never returned a Null. If something goes wrong, it throws and exception, if there's no clients, it returns an empty list. Now my Code looks like
 var myClientList = GetClientList();  
 sendAnnoyingEmailsTo(myClientList);  
   

This is a flavour of the null object pattern. There is no decision to make. There is no spoon "IF".
But that's a detail, it's the The Architectural "IF" that 'causes me to occasionally consider inventive and infantile revenges on both other programmers, and in fairness, on my past self. If you find a comment like this..
 } // closing if (clientObject is typeof(MajorClient))  
   

The comment indicates there is so much code dependent on the "IF" that you cannot see the other brace on screen. It also darkly hints at a programmer cheerfully ignoring virtual functions.

So why is the programmer doing this?
Surely (s)he:

  •  cannot be ignorant of virtual functions? 
  •  cannot fail to realise that a new dependency is being propagated throughout the code?
  •  must know that now every new Client Sub Class will need to be weaved in through every file that uses the "construct"?
The answer is almost certainly in the class hierarchy. It's broken. It's wrong. Something in there does not fit in well. The base class is OK for most of the sub classes, except for just this one case, and well maybe the case here too. So instead of fixing the problem, the The Architectural "IF" is brought to bear. Flick quickly to the matching brace, and you will almost certainly find something like this...

It may even be an "else if".

If your Architecture is creaking, "IF" can fix it for a while, but like using sticky-tape, the repair is at best temporary.