static string legacy_code(int input)
{
// some magic process
const int magicNumber = 7;
var intermediaryValue = input + magicNumber;
return “The answer is ” + intermediaryValue;
}
When dealing with a project more than a few years old, the issue of legacy code crops up time and time again. In this case, you have a function that’s called from lots of different client applications, so you can’t change it without breaking the client apps.
I’m using the code example above to keep the illustration simple, but you have to imagine that this function “legacy_code(int)”, in reality, could be hundreds of lines long, with lots of quirks and complexities. So you really don’t want to duplicate it.
Now, imagine, that as an output, I want to have just the intermediary value, not the string “The answer is …”. My client could parse the number out of the string, but that’s a horrible extra step to put on the client.
Otherwise you could create “legacy_code_internal()” that returns the int, and legacy_code() calls legacy_code_internal() and adds the string. This is the most common approach, but can end up with a rat’s nest of _internal() functions.
Here’s another approach – you can tell me what you think :
static string legacy_code(int input, Action<int> intermediary = null)
{
// some magic process
const int magicNumber = 7;
var intermediaryValue = input + magicNumber;
if (intermediary != null) intermediary(intermediaryValue);
return “The answer is ” + intermediaryValue;
}
Here, we can pass an optional function into the legacy_code function, that if present, will return the intermediaryValue as an int, without interfering with how the code is called by existing clients.
A new client looking to use the new functionality could call;
int intermediaryValue = 0;
var answer = legacy_code(4, i => intermediaryValue = i);
Console.WriteLine(answer);
Console.WriteLine(intermediaryValue);
This approach could return more than one object, but this could get very messy.
