"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
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"?
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.