Encapsulating legacy code..

Legacy code.. sometimes it really sucks to work with that. The best thing we can do with some components written in "old code" is to encapsulate the stuff, translate it into some common sense. Of course, all because we do not have the time yet for refactoring the component.

Suppose we are getting multiple results back out of the old component for the most simple value in software engineering: the BOOL value. You might think if that is a valid question. Well, if you get the values from that other component based on an XML interface… the answer, unfortunately, is YES.

Let me give you some insight into a beautifull encapsulating method for translating the BOOL value of the old component, and also a very DIRTY one:


private static bool XMLAttributeStringToBool(String Value)
{
switch (Value.ToUpper())
{
case "0":
case "FALSE":
case "NO":
case "N":
return false;
case "1":
case "TRUE":
case "YES":
case "Y":
return true;
default:
throw new Exception("Unknown boolean type" );
}
}

Very clear right? We want to get rid of all the different values that the legacy system gave to the True/False values and we simply create a nice typesafe Bool out of it.

Now there is another way to translate values of an XML message, and I would call that the nasty one. It was somewhere hidden in our encapsulation class as well:


private Boolean ConvertToBoolean(string value)
{
if (value == "1" || value.ToLower() == "true" )
{
return true;
}
else
{
return false;
}
}

Ouch!

Do you see the nastiness? Instead of gracefully TELLING US THAT IT CAN NOT TRANSLATE the legacy-value for us, it is simply "assuming" to return false. Just imagine what bugs come out of this…
Horrifying!

Lesson: if you do not know how to translate.. don't do it! Throw exceptions. And if you encounter the exception, enhance that translater-function for the next iteration..