Let’s take a sidestep from the more advanced runtime code generation topic (don’t worry, still more to follow later) and move to easier territory. On a blog about software design, what better topic than encapsulation.
Abstraction, information hiding, and encapsulation are very different, but highly-related, concepts. One could argue that abstraction is a technique that helps us identify which specific information should be visible, and which information should be hidden. Encapsulation is then the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible. – Edward V. Berard
Modern object-oriented languages start to lend features from functional programming languages, like lambdas. They can be used to create anonymous functions using a very concise syntax. One of the often overlooked advantages of anonymous functions beside its conciseness is they can be used to encapsulate logic even further than a private method. When making a method private, it can be accessed by the entire scope of the class, while anonymous functions can only be accessed from the scope they are created in, or passed to.
Consider the following highly inefficient “Hello World!” implementation:
public void HelloWorld()
{
string[] words = new[] { "hello", "pretty", "world" };
Console.WriteLine(
ComplexHelloWorldParsing( words[ 0 ] ) +
words[ 1 ] +
ComplexHelloWorldParsing( words[ 2 ] ) );
}
private static string ComplexHelloWorldParsing( string input )
{
string parsed = input;
// ... plenty of complex specific parsing, only used in HelloWorld.
return parsed;
}
ComplexHelloWorldParsing is – and let’s assume should – only be used inside the HelloWorld method. Still it is visible to the entire class. In such a scenario, where encapsulating the specific behavior doesn’t make sense, I would use the following approach regardless of lines of code inside the delegate.
public void HelloWorld()
{
string[] words = new[] { "hello", "pretty", "world" };
Func complexParsing = s =>
{
string parsed = s;
// ... plenty of complex method specific parsing.
return parsed;
};
Console.WriteLine( complexParsing( words[ 0 ] ) + words[ 1 ] + complexParsing( words[ 2 ] ) );
}
It surprises me not all people agree on this advantage. For the same reason some professional programmers prefer to split functions just to make them smaller, some state lambdas should always be short. They state longer logic should (by a rule of thumb) be placed in a private method. If you know any pro ‘short delegate’ arguments, be sure to let me know. I started a question relating to this topic on Programmers Stack Exchange.
whatheco.de 