Scattered throughout the .NET framework are classes that are intended to appear externally sealed, but internally (by the framework class library developers) open for further extension. Because there is no mechanism to only allow classes to be sealed outside of the current assembly, framework developers at Microsoft use a compensating pattern: internal constructors.

Unfortunately, this has a side effect of making the classes uninstantiable. For the most part, this is not a problem as these classes are given to the developer already instantiated and ready to be consumed.

   1: public class DataReceivedEventArgs : EventArgs

   2: {

   3:     // Fields

   4:     internal string _data;

   5:  

   6:     // Methods

   7:     internal DataReceivedEventArgs(string data);

   8:  

   9:     // Properties

  10:     public string Data { get; }

  11: }

(System.Diagnostics.DataReceivedEventArgs as seen in Reflector. A good example of an example of internal constructor being used in the .NET framework FCL )

A practical example - What about mocking?

Mocking framework objects is the most common case where the internal constructor pattern causes an inconvenience. For the sake of example, image that you intend to test an event handler you just created that consumes DataReceivedEventArgs:

   1: private void NetErrorDataHandler(object SendingProcess, 

   2:     DataReceivedEventArgs ErrorLine)

   3: {

   4:     //Process New Error Data...

   5: }

You may try creating a unit test that passes in a custom DataReceivedEventArgs object with different data strings. Such as:

   1: DataReceivedEventArgs MockEventArgs = new DataReceivedEventArgs();

Unfortunately, you quickly realize that DataReceivedEventArgs can’t be instantiated:

(Actually a lie, DataReceivedEventArgs has a constructor defined but it’s just marked as “Internal”)

One plain solution to this problem would be to decouple your implementation of processing new error data from the event notification. Something like:

   1: private void NetErrorDataHandler(object SendingProcess, 

   2:     DataReceivedEventArgs ErrorLine)

   3: {

   4:     NetErrorData_Implementation(SendingProcess, ErrorLine.Data);

   5: }

   6:  

   7: private void NetErrorData_Implementation(object SendingProcess, 

   8:     string ErrorLineData) 

   9: {

  10:     //Process New Error Data...

  11: }

Now, you can test the implementation freely. This is a completely valid way to sidestep the uninstantiable object issue with testing.

Of course, you’ve just paid for your new ability with an entirely new method and a minimum of four new lines of code to maintain. Following this pattern with many events could add up to a significant maintenance cost down the road.

Instantiating the Uninstantiable

An alternative to changing your implementation is to use a mixture of reflection and serialization helper methods to create your target object without calling any constructors, and then manually set its private/internal fields.

Yes, you heard me correctly, create an object without calling any constructors.

This is not only possible, but easy (about one line of code in c#), believe it or not! Simply call GetUninitializedObject. Let me show you an example:

   1: DataReceivedEventArgs MockEventArgs =

   2:     (DataReceivedEventArgs)System.Runtime.Serialization.FormatterServices

   3:      .GetUninitializedObject(typeof(DataReceivedEventArgs));

(Creates a new DataReceivedEventArgs object called MockEventArgs)

At this point in execution, the zombie object will leap to life, with no soul (or state for that matter).

The first thing you should be concerned about is plugging in some values for the private fields, which will be null and performing any critical rolls the constructor would have.

I strongly recommend studying the constructor of your target object in a tool such as Reflector, before initializing it yourself.

Here’s an example of setting the (single) internal field on MockEventArgs:

   1: FieldInfo[] EventFields = typeof(DataReceivedEventArgs)

   2:     .GetFields(

   3:         BindingFlags.NonPublic |

   4:         BindingFlags.Instance |

   5:         BindingFlags.DeclaredOnly);

   6:  

   7: if (EventFields.Count() > 0)

   8: {

   9:     EventFields[0].SetValue(MockEventArgs, “This is dynamically a injected value” );

  10: }

  11: else

  12: {

  13:     throw new ApplicationException(

  14:         "Failed to find any fields!");

  15: }

That’s it! Now the MockEventArgs object can be used just as if it came from inside the framework and your test method can emulate the event:

   1: NetErrorDataHandler(new Object(), MockEventArgs);

Making it Reusable

Obviously typing out this code every time you needed to mock up an uninstantiable object would be a major headache. I packaged these into a neat set of methods that makes it easy to mock up these difficult objects in only a few lines of code. Here’s the finished product:

(Updated on August 31st)

   1:         /// <summary>

   2:         /// Instantiates T without calling a constructor.

   3:         /// Works well with otherwise uninstantiable objects.

   4:         /// </summary>

   5:         /// <typeparam name="T">Anything that does NOT derive

   6:         /// from ContextBoundObject.</typeparam>

   7:         /// <param name="Values">A dictionary of values to initialize

   8:         /// the object in place of a constructor.</param>

   9:         /// <returns>The newly created and instantiated object.</returns>

  10:         public static T Create<T>(Dictionary<string, object> Values)

  11:         {

  12:  

  13:             if (Values == null)

  14:                 throw new ArgumentNullException("Values", "Values is null.");

  15:  

  16:             return Fill<T>(

  17:                 CreateBlank<T>(),

  18:                 Values);

  19:  

  20:         }

  21:  

  22:         private static T CreateBlank<T>()

  23:         {

  24:  

  25:             if (typeof(ContextBoundObject).IsAssignableFrom(typeof(T)) == true)

  26:             {

  27:                 throw new ApplicationException(

  28:                     "You can't use types that derive from ContextBoundObject.");

  29:             }

  30:  

  31:             return (T)System.Runtime.Serialization.FormatterServices

  32:                  .GetUninitializedObject(typeof(T));

  33:         }

  34:  

  35:  

  36:         private static T Fill<T>(T Source, Dictionary<string, object> Values)

  37:         {

  38:             if (Source == null)

  39:                 throw new ArgumentNullException("Source", "Source is null.");

  40:  

  41:             if (Values == null)

  42:                 throw new ArgumentNullException("Values", "Values is null");

  43:  

  44:             if (Values.Count == 0)

  45:                 return Source;

  46:  

  47:             FieldInfo[] EventFields = typeof(T)

  48:                 .GetFields(

  49:                     BindingFlags.NonPublic |

  50:                     BindingFlags.Public |

  51:                     BindingFlags.Instance |

  52:                     BindingFlags.DeclaredOnly);

  53:  

  54:             if (EventFields != null && EventFields.Count() > 0)

  55:             {

  56:                 foreach (FieldInfo Field in EventFields)

  57:                 {

  58:                     if (Values.ContainsKey(Field.Name) == true

  59:                         && Field.FieldType

  60:                             .IsAssignableFrom(Values[Field.Name]

  61:                                 .GetType()) == true)

  62:                     {

  63:                         Field.SetValue(Source, Values[Field.Name]);

  64:                     }

  65:                 }

  66:             }

  67:  

  68:             return Source;

  69:  

  70:         }

Example Usage:

   1: var Values = new Dictionary<string, object>()

   2:     {

   3:         {"_data","This is an injected string"}

   4:     };

   5:  

   6: DataReceivedEventArgs MockEventArgs

   7:     = RMock.MockServices.Create<DataReceivedEventArgs>(Values);

Robert Uncategorized

A FizzBuzz problem is a quick litmus test designed to identify incompetent developers. These tiny coding exercises are designed to be easy and fast to implement using fundamental programming know-how. If you have a good grasp of programming, you should be able to solve these problems in a few minutes without much hassle.

Imran Ghory initially coined the term and came up with the most well known puzzle:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

The run of the mill correct solution is something like:

   1: static void FizzBuzzClassic()

   2: {

   3:  

   4:     for (int x = 1; x <= 100; x++)

   5:     {

   6:  

   7:         string WorkingLineContents = string.Empty;

   8:  

   9:         if (x % 5 != 0 && x % 3 != 0)

  10:         {

  11:             //Neither a multiple of 3 or 5

  12:             WorkingLineContents = x.ToString();

  13:         }

  14:         else

  15:         {

  16:             //Multiple of three ("Fizz"), five ("Buzz"), or both ("FizzBuzz")

  17:             WorkingLineContents = (x % 3 == 0) ? "Fizz" : string.Empty;

  18:             WorkingLineContents += (x % 5 == 0) ? "Buzz" : string.Empty;

  19:         }

  20:  

  21:         Console.WriteLine(WorkingLineContents);

  22:  

  23:     }

  24:  

  25:     Console.ReadKey();

  26:  

  27: }

If you toss readability to the wind and want to scrawl out a nearly-one-line* solution by syntactically abusing the ternary operator, it would look something like this:

   1: static void FizzBuzzLessReadable()

   2: {

   3:  

   4:     Enumerable.Range(1,100).ToList().ForEach(

   5:                 n => Console.WriteLine(

   6:                     (n%3==0) ? (n%5==0) ? "FizzBuzz" : "Fizz"

   7:                          : (n%5==0) ? "Buzz" : n.ToString()

   8:             ));

   9:  

  10:     Console.ReadKey();

  11:  

  12: }

(*One semicolon at least. Also: replace Enumerable.Range & Lambda with a ‘for’ loop if you can’t use Framework 3.5)

Yes, it’s depressing that there are still developers in our trade that are unable to create a working for loop in under ten minutes. However, this is an easy topic and has already been beaten to death again and again.

Instead of discussing developer competence, I wanted to take the simple problem and enumerate through interesting ways of solving it that do not involve a for loop with hard coded logic. These solutions illustrate interesting patterns that can be used to solve other more difficult problems.

I hacked together a few fun answers to the problem in my free time that leverage the LINQ extension methods to create something that is more dynamic. I humbly present to you two horribly overly engineered FizzBuzz solutions:

Solution 1 – Combined Dynamically Generated Lists

The correct output involves four constituent parts: Fizz, Buzz, FizzBuzz, and the number. If you think carefully, you could imagine the problem as four parallel lists layered on top of each other. Something like:

Each list is responsible for providing the correct value at each index. The solution to the problem is just all four lists flattened (combined) into one. I put together a generic extension method that does just that:

   1: private static IEnumerable<T> JoinByIndex<T>(this List<IEnumerable<T>> Lists)

   2: {

   3:  

   4:     if (Lists == null)

   5:         throw new ArgumentNullException("Lists", "Lists is null.");

   6:  

   7:     var Cache = new List<IEnumerator<T>>();

   8:     Lists.ForEach(l => Cache.Add(l.GetEnumerator()));

   9:  

  10:     while (Cache.All(e => e.MoveNext() == true) == true) 

  11:     {

  12:         yield return Cache.First(e => e.Current != null).Current;

  13:     }

  14:  

  15: }

All this does is squish a set of lists into one resulting master list. The value for each index of the resulting list is the first non-null value found at the same index in the source lists (all of the bold values in the table above).

Continuing to work backwards, the missing ingredient is now the source lists. We could have flat lists that have been pre-calculated up to a certain point, but that wouldn’t be very dynamic, plus it would be a lot of extra typing. Instead, I built a (generic) dynamic list generator that takes in an algorithm to stipulate the list value at each point, and uses the iterator block pattern to have the values calculated on demand. It’ll work up to int.MaxValue(2,147,483,647) but you could easily extend that if needed by switching to unsigned integers or another data type.

Here is the dynamic list implementation:

   1: static IEnumerable<T> DynamicList<T>(Func<int, T> Generator)

   2: {

   3:  

   4:     if (Generator == null)

   5:         throw new ArgumentNullException("Generator", "Generator is null.");

   6:  

   7:     for (int x = 1; x <= int.MaxValue; x++)

   8:     {

   9:         yield return Generator(x);

  10:     }

  11:  

  12: }

To create the dynamic lists, all we need to do is feed in the algorithm that dictates what the list value should be for each index. Example:

   1: IEnumerable<string> FizzList =

   2:                 DynamicList<string>((n) => (n % 3 == 0 && n % 5 != 0) ? "Fizz" : null);

(“For each index divisible by three, but not divisible by five, the value is Fizz”)

Now we have all of the tools we need to build our dynamic list solution. All that’s needed is to create the four dynamic lists, combine them using JoinByIndex(), Take the first 100 results, generate the list, and output each item to the console. Here’s what that looks like:

   1: static void FizzBuzzIEnumerables()

   2: {

   3:  

   4:     (new List<IEnumerable<string>> 

   5:         { 

   6:             DynamicList((n) => (n % 3 == 0 && n % 5 != 0) ? "Fizz" : null),

   7:             DynamicList((n) => (n % 5 == 0 && n % 3 != 0) ? "Buzz" : null),

   8:             DynamicList((n) => (n % 5 == 0 && n % 3 == 0) ? "FizzBuzz" : null),

   9:             DynamicList((n) => (n % 5 != 0 && n % 3 != 0) ? n.ToString() : null)

  10:         })

  11:             .JoinByIndex()

  12:             .Take(100)

  13:             .ToList()

  14:             .ForEach(

  15:                 s => Console.WriteLine(s)

  16:                     );

  17:  

  18:     Console.ReadKey();

  19:  

  20: }

An important item to note is that none of the list index values are calculated unless they are requested or explicitly converted ToList() such as on line 13.

Solution 2 – List of Functions (Bonus: Closures & Currying)

Similar to the first solution, this method simply defines a set of algorithms for each constituent part and then uses the fist matching one at each index. By eliminating IEnumerable as the representation of the output we can save a great deal of work while keeping the same fundamental idea:

   1: using FBProcessor = System.Func<int, string>;

(…)

   1: static void FizzBuzzListOfFunctions()

   2: {

   3:  

   4:     var Processors = new List<FBProcessor>() 

   5:     {

   6:         (n) => (n % 3 == 0 && n % 5 != 0) ? "Fizz" : null,

   7:         (n) => (n % 5 == 0 && n % 3 != 0) ? "Buzz" : null,

   8:         (n) => (n % 5 == 0 && n % 3 == 0) ? "FizzBuzz" : null,

   9:         (n) => (n % 5 != 0 && n % 3 != 0) ? n.ToString() : null,

  10:     };

  11:  

  12:     System.Func<int, FBProcessor> MatchingProcessor =

  13:         (n) => Processors.Find(p => p(n) != null);

  14:  

  15:     Enumerable.Range(1, 100).ToList().ForEach(

  16:         n => Console.WriteLine(MatchingProcessor(n)(n)));

  17:  

  18:     Console.ReadKey();

  19:  

  20: }

This implementation uses closures (“Processors” reference in the MatchingProcessor lambda) and currying (see MatchingProcessor return type – FBProcessor - a function) to be as succinct as possible.

So What?

The fun part about these solutions is how easy they are to modify. They could even be modified dynamically at runtime. You could feed in more lists or functions without a problem. If you had a similar problem on a much larger scale, the syntax of lists or lists of functions would probably be a lot more readable than a set of if-then statements.

Additionally, since the lists or lists of functions are only evaluated until a matching one is found, you could tune the performance by reordering. If you encapsulated the FBProcessor functions into objects that kept track of how many positive matches were made you could (quite easily) automatically reorder them at runtime.

Robert Uncategorized

The Black Belt C# series aims to uncover powerful but lesser-known features of the C# language. Each article introduces a few of these features and shows you how to use them to take your programming to the next level.

The “as” Keyword

The as operator is a quick way to try to cast an object to a specific type. The operator returns null if the cast fails, instead of raising an exception.

There are cases where you may have an incoming object that may be a specific type. Take a look at this X10 (home automation) example:

   1: private class X10Device { }

   2: private class DoorSensor : X10Device { }

   3: private class LightSwitch : X10Device { public bool On { get; set; } }

   4:  

   5: private void Controller_DeviceChangedState(X10Device Source)

   6: {

   7:     //...respond to device change based on type

   8: }

In this example, imagine an X10 controller is wired up to our DeviceChanged…() method and it’s called every time an x10 device changes state. Any type of X10 device could be passed into the method and we can’t be sure of the exact type of device until we check for it at runtime.

Lets say that we only want to pay attention to light switches and ignore the other device types. There are a few ways we could attempt to single out light switches and start working with them.

Here’s a traditional way of doing this:

   1: private void Controller_DeviceChangedState(X10Device Source)

   2: {

   3:  

   4:     if (Source is LightSwitch)

   5:     {

   6:         LightSwitch SourceLightSwitch = (LightSwitch)Source;

   7:  

   8:         if (SourceLightSwitch.On == true)

   9:         {

  10:             MessageBox.Show("Light Turned On!");

  11:         }

  12:  

  13:     }

  14:  

  15: }

This example uses the “is” keyword to single out light switches. Then it creates a new variable that is certainly a light switch and wires it up to the Source reference knowing with full certainty that the cast will succeed.

Here’s an alternative way to accomplish the same thing, by using the “as” keyword:

   1: private void Controller_DeviceChangedState(X10Device Source)

   2: {

   3:  

   4:     LightSwitch SourceLightSwitch = Source as LightSwitch;

   5:  

   6:     if (SourceLightSwitch != null)

   7:     {

   8:         if (SourceLightSwitch.On == true)

   9:         {

  10:             MessageBox.Show("Light Turned On!");

  11:         }

  12:     }

  13:  

  14: }

If you ask me, this example is a little bit more succinct and readable. It also neatly groups together the case for Source being null or a different type (such as a DoorSensor).

If you can afford a slightly lower readability, the “as” statement also allows for a more compressed syntax where the cast attempt and check are performed all on the same line:

   1: LightSwitch SourceLightSwitch = null;

   2:  

   3: if ((SourceLightSwitch = Source as LightSwitch) != null)

   4: {

   5:     if (SourceLightSwitch.On == true)

   6:     {

   7:         MessageBox.Show("Light Turned On!");

   8:     }

   9: }

The “using” Keyword

The using keyword is an unusual case of two separate (but related) keywords rolled into one name.

Aliases (the using directive)

Aliases can save you a lot of time when you have oft-used complex generics and namespaces. The using directive allows you to define the composition of these types in one place instead of typing them out over and over again. Here’s an example with nested dictionaries:

   1: using ComplexDictionary = Dictionary<int, Dictionary<string, List<string>>>;

   2:  

   3: public partial class Main : Form

   4: {

   5:     ComplexDictionary MainComplexDictionary = new ComplexDictionary();

   6:     ComplexDictionary SecondaryComplexDictionary = new ComplexDictionary();

   7:  

   8:     public Main()

   9:     {

  10:         InitializeComponent();

  11:     }

  12:  

  13: }

As you can see, the using directive safely abstracts the “ComplexDictionary” type to a single location and is easily readable. Changing the ComplexDictionary type would be a simple task, no matter how many times it’s used throughout the code. Furthermore, creating further new ComplexDictionary variables is now a snap. Here’s the ugly alternative:

   1: public partial class Main : Form

   2: {

   3:     Dictionary<int, Dictionary<string, List<string>>> MainDictionary = 

   4:         new Dictionary<int, Dictionary<string, List<string>>>();

   5:  

   6:     Dictionary<int, Dictionary<string, List<string>>> SecondaryDictionary = 

   7:         new Dictionary<int, Dictionary<string, List<string>>>();

   8:  

   9:     public Main()

  10:     {

  11:         InitializeComponent();

  12:     }

  13:  

  14: }

Explicit Object Scope (the using statement)

The using statement is a bulletproof way to use disposable objects. Here’s an example:

   1: using (Form NewForm = new Form())

   2: {

   3:     NewForm.Enabled = true;

   4:     NewForm.StartPosition = FormStartPosition.CenterScreen;

   5:     NewForm.Size = new Size() { Height = 100, Width = 100 };

   6:     NewForm.ShowDialog();

   7: }

In this example, a new form is created and displayed and execution blocks at ShowDialog() until the form is closed. As soon as the form is closed by the user NewForm.Dispose() is called and NewForm goes out of scope - automatically.

This is functionally equivalent to the following code:

   1: {

   2:     Form NewForm = new Form();

   3:  

   4:     try

   5:     {

   6:         NewForm.Enabled = true;

   7:         NewForm.StartPosition = FormStartPosition.CenterScreen;

   8:         NewForm.Size = new Size() { Height = 100, Width = 100 };

   9:         NewForm.ShowDialog();

  10:     }

  11:     finally

  12:     {

  13:         if (NewForm != null) ((IDisposable)NewForm).Dispose();

  14:     }

  15:  

  16:  

  17: }

The using statement makes it easy to contain object scope and ensure that objects are disposed properly every time. Taking advantage of the using statement is a great way to improve quality while not sacrificing readability.

The “checked” and “unchecked” Keywords

The checked and unchecked keywords are useful for controlling what happens when an arithmetic operation overflows. By default, .NET projects created in Visual Studio will allow arithmetic overflow to happen silently and without warning.

Default Overflow Example – Outputs “-2” with default project configuration

   1: //32,767 is the maximum value for a short 

   2: short FirstValue = 32767;

   3: short SecondValue = 32767;

   4:  

   5: //Outputs -2

   6: Debug.WriteLine((short)(FirstValue + SecondValue));

Global overflow checking is not turned on by default because it’s a significant performance hit and arithmetic overflow is not really a common occurrence.

You can turn on overflow checking by opening up your project advanced build settings (left) and checking the appropriate box but it’s generally a better practice to selectively enable overflow checking instead.

These two keywords were created to give developers just that precision level of control needed over overflow checking. To use the checked keyword, simply wrap your math statement inside a “Checked { }” block.

Tip:

The “Checked” and “Unchecked” keywords only apply to code directly in the specified block and do not extend to arithmetic in nested function calls. Calling a function from within your checked block will not cause overflow checking to occur inside the called function.

Checked Overflow Example – Raises Exception

   1: //32,767 is the maximum value for a short 

   2: short FirstValue = 32767;

   3: short SecondValue = 32767;

   4:  

   5: checked

   6: {

   7:     //Raises Overflow Exception

   8:     Debug.WriteLine((short)(FirstValue + SecondValue));

   9: }

Any overflows occurring inside the parenthesis will safely raise an OverflowException, failing loudly:

Correspondingly, if you do enable global overflow checking, you can selectively disable it by wrapping statements inside an “Unchecked { }” block. This is especially useful for reaping performance benefits in tight loops where you can prove that overflow will not occur. Again, unchecked { } will only have performance benefits if you have manually enabled overflow checking.

Unchecked Example – Assumes global overflow checking manually enabled

   1: unchecked

   2: {

   3:     //Index will never exceed 3,276.

   4:     for (int Index = 0; Index <= 3276; Index++)

   5:     {

   6:         //Will never overflow – Index * 10 will never exceed 32,760

   7:         Debug.WriteLine((short)(Index * 10));

   8:     }

   9: }

How does overflow checking work?

Overflow checking is effectively added into your project at compile time. Turning on global overflow checking or using checked { } blocks causes the compiler to generate slightly different IL to accommodate your request. Here’s the IL from the previous example of adding two shorts:

Unchecked - Adds FirstValue and SecondValue

   1: .maxstack 2

   2: .locals init (

   3:     [0] int16 FirstValue,

   4:     [1] int16 SecondValue)

   5: L_0000: nop 

   6: L_0001: ldc.i4 0x7fff

   7: L_0006: stloc.0 

   8: L_0007: ldc.i4 0x7fff

   9: L_000c: stloc.1 

  10: L_000d: nop 

  11: L_000e: ldloc.0 

  12: L_000f: ldloc.1 

  13: L_0010: add 

  14: L_0011: conv.i2 

  15: L_0012: box int16

  16: L_0017: call void [System]System.Diagnostics.Debug::WriteLine(object)

  17: L_001c: nop 

  18: L_001d: nop 

  19: L_001e: ret 

Checked – Adds FirstValue and SecondValue with Overflow Check

   1: .maxstack 2

   2:  .locals init (

   3:      [0] int16 FirstValue,

   4:      [1] int16 SecondValue)

   5:  L_0000: nop 

   6:  L_0001: ldc.i4 0x7fff

   7:  L_0006: stloc.0 

   8:  L_0007: ldc.i4 0x7fff

   9:  L_000c: stloc.1 

  10:  L_000d: nop 

  11:  L_000e: ldloc.0 

  12:  L_000f: ldloc.1 

  13:  L_0010: add.ovf 

  14:  L_0011: conv.ovf.i2 

  15:  L_0012: box int16

  16:  L_0017: call void [System]System.Diagnostics.Debug::WriteLine(object)

  17:  L_001c: nop 

  18:  L_001d: nop 

  19:  L_001e: ret 

As you can see, the checked block doesn’t radically alter the output IL. Can you spot the overflow check? In the checked (second) example, the compiler emitted “add.ovf” on line 13 instead of “add”. That’s pretty much it (apart from another check on line 14 for an implicit conversion).

The special IL “add.ovf” performs an overflow check before moving the result onto the stack. Intermediate language also contains similar versions for subtraction (sub.ovf), multiplication (mul.ovf), and numeric conversion.

Robert Black Belt, C# as, checked, keywords, overflow, unchecked, using

The Black Belt C# series aims to uncover powerful but lesser-known features of the C# language. Each article introduces a few of these features and shows you how to use them to take your programming to the next level.
 

The “??” Operator

This granule of syntactical sugar, known as the the “Null Coalescing Operator”, provides a quick way to check and react to null values. As an example, lets say we have a widget name which came from an external source. Programming defensively, it’s always good idea to check reference types for null before working with them. Here’s an example of the code that may be written without using the operator:

   1: string WidgetName = DivineWidgetNameFromEther();

   2: 

   3: if (WidgetName != null)

   4: {

   5:     System.Diagnostics.Debug.WriteLine(WidgetName);

   6: }

   7: else

   8: {

   9:     System.Diagnostics.Debug.WriteLine("WidgetName is null");

  10: }

   1: string WidgetName = DivineWidgetNameFromEther();

   2: 

   3: System.Diagnostics.Debug.WriteLine(WidgetName ?? "WidgetName is null");

This, vastly superior version, produces identical output to the first. If WidgetName is not null, then it’s simply written to the output window. However, if WidgetName does happen to be null, “WidgetName” is null” is safely written instead. This is a great way to unobtrusively improve quality in your program without sacrificing readability.

Black Belt Tip: Lazy Instantiation Made Easy

Leverage the null coalescing operator to achieve lazy instantiation with manually implemented properties:

   1: private List<Widget> _Widgets = null;

   2: public List<Widget> Widgets

   3: {

   4:     get { return _Widgets ?? (_Widgets = new List<Widget>()); }

   5: }

Automatic Properties

Auto-Implemented properties are a nice shorthand (C# 3+) for expressing a public property and a private (although inaccessible) field… without having to type all of that out. Have a look:

   1: /// <summary>

   2: /// This is a valid property and NOT a field.

   3: /// </summary>

   4: private string WidgetDescription { get; set; }

This is a perfectly valid property, backed by a private field that is created automatically but is inaccessible. Here is the disassembly:

   1: .property instance string WidgetDescription

   2: {

   3:     .get instance string BlackBeltCSharp.Form1::get_WidgetDescription()

   4:     .set instance void BlackBeltCSharp.Form1::set_WidgetDescription(string)

   5: }

   6: 

   7: 

   8: .field private string <WidgetDescription>k__BackingField

   9: {

  10:     .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()

  11: }

You can designate a different scope for the getter and for the setter, without leaving automatic properties. For Example:

   1: public string WidgetDescription { get; private set; }

Advanced Generics

Taking advantage of generics, introduced in .NET 2.0, is a great way to improve your productivity while layering on type-safety and added performance benefits (up to 200% when working with value types such as integers). To review, here is a sample generic method and usage:

Sample Generic Method

   1: /// <summary>

   2:  /// Selects and returns an item at (pseudo)random from the supplied list

   3:  /// </summary>

   4:  /// <typeparam name="T">Any Type</typeparam>

   5:  /// <param name="FromList">Source list from which to pick an item from</param>

   6:  /// <returns>(pseudo)Randomly selected item</returns>

   7:  private T SelectRandom<T>(List<T> FromList)

   8:  {

   9:      Debug.Assert(FromList != null, "FromList (of type " + typeof(T).Name + ") is null.");

  10: 

  11:      //Picks a pseudo-random index in "FromList"

  12:      int RandomlySelectedIndex =

  13:          new Random((int)(DateTime.Now.Ticks % 0x7FFFFFFF)).Next(FromList.Count);

  14: 

  15:      //Returns item at randomly chosen index

  16:      return FromList[RandomlySelectedIndex];

  17: 

  18:  }

Sample Usage

   1: List<String> Names = new List<String>() { "Daniel Dennett", "John Locke", "Saul Kripke" };

   2: List<int> Numbers = new List<int>() { 2, 5, 7 };

   3: 

   4: Debug.WriteLine("Read " + SelectRandom<int>(Numbers) +

   5:     " books from " + SelectRandom<string>(Names));

The usage outputs something like “Read 7 books from John Locke”. The important thing to notice is the use of the same generic “SelectRandom” method for both integers and strings.

Type Inference

It’s possible for the c# compiler to infer the type to be used. For example, this is perfectly legal:

   1: Debug.WriteLine("Read " + SelectRandom(Numbers) +

   2:     " books from..." + SelectRandom(Names));

Where T : new()

This special constraint limits acceptable types to those which feature a public, parameterless constructor. This allows for some really special syntax inside a generic class. Have a look:

   1: class ConstrainedGenericClass<T> where T : new()

   2: {

   3:     private T NewItemOfTypeT = new T();

   4: }

Using the “new()” constraint unlocks the ability to easily instantiate a new version of the specified class type. This is just the tip of the iceberg, for a complete list of constraints, visit:

http://msdn.microsoft.com/en-us/library/6b0scde8(VS.80).aspx

Currying

Likely the most advanced and confusing topic surrounding generics in c#, currying is the process of distributing an argument list over several functions, instead of one. For example, instead of having one function that takes three arguments, you can have three functions taking one argument, each building on the next. Let me show you a few examples:

Example Without Currying

   1: private void DoWork()

   2: {

   3:     //Outputs 11

   4:     Debug.WriteLine(AddNumbers(1, 3, 7));

   5: }

   6: 

   7: //Returns sum of three integers

   8: private int AddNumbers(int X, int Y, int Z)

   9: {

  10:     return X + Y + Z;

  11: }

Example With Currying

   1: private void DoWork()

   2: {

   3:     var CurriedNumberAdder = Curry(AddNumbersWork);

   4: 

   5:     //Outputs 11

   6:     Debug.WriteLine(CurriedNumberAdder(1)(3)(7));

   7: }

   8: 

   9: Func<int,int,int,int> AddNumbersWork = (X, Y, Z) => X + Y + Z;

  10: 

  11: //Standard Curry Function

  12: private Func<T1, Func<T2, Func<T3, T4>>> Curry<T1, T2, T3, T4>(Func<T1, T2, T3, T4> function)

  13: {

  14:     return a => b => c => function(a, b, c);

  15: }

If you haven’t yet delved into functional programming then this example may be confusing and the benefit may not be immediately obvious. What’s happening here is each function calls the next, while contributing its argument. This process continues until it gets to the last function (X + Y + Z), which in this case defines what should happen with the arguments that have been assembled.

There are a few interesting benefits to this massive overhead of complexity. First, it’s possible to slowly assemble the function in bits and pieces over many lines. Example:

Example of Calling One Argument at a Time

   1: private void DoWork()

   2: {

   3:     var CurriedNumberAdder = Curry(AddNumbersWork);

   4: 

   5:     //...Do Something Else Here

   6: 

   7:     var FirstResult = CurriedNumberAdder(1);

   8: 

   9:     //...Do Something Else Here

  10: 

  11:     var SecondResult = FirstResult(3);

  12: 

  13:     //Outputs 11

  14:     Debug.WriteLine(SecondResult(7));

  15: }

This may be useful for reducing the scope and span of variables that contribute to your curried function. More importantly, by encapsulating combinations of arguments inside a variable, it opens up new possibilities for reuse:

Example Reusing Curried Functions

   1: private void DoWork()

   2: {

   3:     var CurriedNumberAdder = Curry(AddNumbersWork);

   4: 

   5:     var FirstResult = CurriedNumberAdder(1);

   6:     var SecondResult = FirstResult(3);

   7: 

   8:     //Outputs 5

   9:     Debug.WriteLine(SecondResult(1));

  10: 

  11:     //Outputs 14

  12:     Debug.WriteLine(SecondResult(10));

  13: 

  14:     //Outputs 104

  15:     Debug.WriteLine(SecondResult(100));

  16: }

Robert Black Belt, C# automatic properties, black belt, closures, currying, generics, lambdas, null coalescing operator, type inference

Popularized by Python and Ruby, the lambda expression is a powerful shorthand that can be used to significantly speed up c# development. This post deals entirely with using lambda expressions in everyday development, and sidesteps the esoteric mathematical logic that makes them intimidating.

Lambda What?

A Lambda expression in c# is simply a piece of syntactical sugar for fleshing out a function body where you would normally plug in a delegate (pointing to a function somewhere else). This saves you two or three lines of code per call, speeding up your development (where delegates are required) to light speed and making your code more maintainable.

Because lambdas can only be used where delegates are required, your initial benefit from learning them may be limited. Before looking into lambdas, I avoided using functions in the .NET base class library that required delegates because of the added hassle. Now, after learning how to use lambdas, I seek them out!

Lastly, are you familiar with anonymous methods? Lambda expressions are very similar - just a slightly shorter syntax. Anonymous methods and lambdas compile to the same intermediate language (and have the same performance as a result).

What does a lambda expression look like?

In the example above, Name => Name.StartsWith(“O”) is the lambda expression. All it does is check if the “Name” passed into it starts with a given letter and returns True/False. The Find() function (not lambda-related) runs this lambda expression against each list item until a match is found. You could use a delegate to another function (like the one below) or an anonymous method in its place, but it would be a lot more code either way.

This expression is roughly equivalent to the non-lambda function:

(Which could have been plugged into FruitNames.Find() using a delegate by the way. All that was accomplished by using the lambda was saving a few lines of code.)

“Name”

Name is the function argument. We could have named this “FruitName”, “F”, or anything else. However, we would have had to remember to change it in the function body at the same time. Lambdas automatically infer variable types from the parent signature. In this case, StartsWith() requires a single string argument, causing “Name” to typed as a string.

“=>”

This is the important symbol that tells c# that you are using a lambda expression. It is absolutely required for every lambda expression that you write. Arguments go on the left and your function body goes on the right. Read as “goes to”.

“Name.StartsWith(“O”)”

Is plain c# and also the meat of the expression. This simply returns true if the function argument “Name” begins with the letter “O” or false if it does not. In this example, it’s only one line. However, lambdas may be expanded to multiple lines (just wrap your function body in squiggly brackets like any other method) In this case, it is required that we return a Boolean because the parent “Find()” requires a Predicate (Boolean return type):

(Predicate simply takes in one argument of a given type and returns a Boolean)

Real-World Examples

Now that you have a basic understanding of what a lambda expression is, and how it might be useful (less code), take a look at a few practical code examples.

Predicate Delegates

A predicate is just a function that returns true or false. Imagine helping a friend sort through a box of old items. You pick up each item out of the box and your friend (after looking at the item) either says “throw away” or “keep”. Your friend is acting as a predicate.

Predicates are extremely useful for filtering lists of items and you will find them throughout the framework for this reason. In the first example in this article we used a predicate to sort through a list of fruit by looking at the first letter of each fruit name.

Here is another example using objects instead of strings:

   1: private class Book

   2:  {

   3:      public string Author { get; set; }

   4:      public string Name { get; set; }

   5:      public DateTime Published { get; set; }

   6:  }

   7:  

   8:  //Create and fill a list of books

   9:  private List<Book> Books = new List<Book> { 

  10:      new Book { Author="Mcconnell",Name="Code Complete", Published=new DateTime(1993,05,14) },

  11:      new Book { Author="Sussman",Name="SICP (2nd)", Published=new DateTime(1996,06,01) },

  12:      new Book { Author="Hunt",Name="Pragmatic Programmer", Published=new DateTime(1999,10,30) },

  13:  };

  14:  

  15:  

  16:  private IEnumerable<Book> BooksPublishedAfter1995()

  17:  {

  18:      return Books.FindAll(Book => Book.Published > new DateTime(1995, 12, 31));

  19:  }

In this example “BooksPublishedAfter1995()” uses a lambda expression as a predicate to compare each when each book was published to a specific date. This function returns a new collection of books containing just SICP and Pragmatic Programmer.

Here’s the a similar multiline lambda that returns books published between 1991 and 1997:

   1: private IEnumerable<Book> BooksPublishedBetween1991and1997()

   2: {

   3:     return Books.FindAll(Book => {

   4:  

   5:         return Book.Published >= new DateTime(1991, 01, 01) &&

   6:         Book.Published <= new DateTime(1997, 12, 31);

   7:     

   8:     });

   9: }

As you can see, it would be excessive to type out a separate function just for this simple piece of logic. Lambda statements are ideal for this type of filtering.

Don’t Forget to stay DRY

(Don’t Repeat Yourself) Lambdas and anonymous methods are a power tools that should be used carefully. Remember to identify and move common predicates into shared functions early instead of using repeated Lambdas throughout your code and creating a maintenance nightmare.

 

Absolutely Minimalistic Threading

It is possible to spawn new threads using just the code contained in the lambda statement. In fact, you can do it in only a few lines. A good example for this is when you need to open up a webpage in the default browser from a windows forms application but don’t want the user interface to skip a beat or lock up (as is the case with some firewall software). Lambda expressions paired with a new thread will do the trick:

   1: (new System.Threading.Thread(()=> {

   2:  

   3:     try

   4:     {

   5:         System.Diagnostics.Process.Start("http://www.example.com");

   6:     }

   7:     catch (Win32Exception StartException)

   8:     {

   9:         //Likely caused by firewall software such as ZoneAlarm

  10:         MessageBox.Show("Failed to open URL.");

  11:     }

  12:  

  13: })).Start();

If you look carefully, you will notice that “()” is used on the left hand side of the lambda. This simply indicates that no arguments are to be used.

For more cool threading lambda expression examples for c#, have a look at my Threading Tips and Tricks post.

Robert C#, Introductions anonymous methods, delegates, introduction, lambda expressions, predicates, threading