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);

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.

Uncategorized