Brendan Enrick

Daily Software Development

Implementing IEnumerable and IEnumerator

Working with a foreach loop is the primary reason to implement the IEnumerable and IEnumerator interfaces. You’ll want one of each of these to work with the loop.

I am going to do an example DateRange class which will implement IEnumerable<DateTime> and will allow us to iterate through a non-existent collection of DateTime objects.

Note: I am aware of the fact that I could achieve the same result with a for loop. I find the foreach loop more readable.

First we need to create a basic DateRange class. A range can be defined as a StartDate and an EndDate, so I’ll start there.

public class DateRange
{
    public DateRange(DateTime startDate, DateTime endDate)
    {
        StartDate = startDate;
        EndDate = endDate;
    }
 
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
}

So this DateRange could be useful on its own, but we want to be able to iterate this collection using a foreach. So to start we need to implement the IEnumerable<DateTime> interface.

public class DateRange : IEnumerable<DateTime>
{
    public DateRange(DateTime startDate, DateTime endDate)
    {
        StartDate = startDate;
        EndDate = endDate;
    }
 
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
 
    public IEnumerator<DateTime> GetEnumerator()
    {
        return new DateRangeEnumerator(this);
    }
 
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

 

Notice here that we now need to get the IEnumerator<DateTime> object in the GetEnumerator() method. I jumped the gun a bit and I’ve called a class that doesn’t exist yet. I’ll make another class and implement the required methods for the IEnumerator interface.

public class DateRangeEnumerator : IEnumerator<DateTime>
{
    private int _index = -1;
    private readonly DateRange _dateRange;
 
    public DateRangeEnumerator(DateRange dateRange)
    {
        _dateRange = dateRange;
    }
 
    public void Dispose()
    {
    }
 
    public bool MoveNext()
    {
        _index++;
        if (_index > (_dateRange.EndDate - _dateRange.StartDate).Days)
            return false;
        return true;
    }
 
    public void Reset()
    {
        _index = -1;
    }
 
    public DateTime Current
    {
        get { return _dateRange.StartDate.AddDays(_index); }
    }
 
    object IEnumerator.Current
    {
        get { return Current; }
    }
}

 

These are the handful of methods we implement for the IEnumerator<DateTime> interface. These are all about moving to the next object and getting the current object. Resetting and Disposal of the object are less important, so make sure you read MoveNext and Current.

Keep in mind here that I could have used a collection for this, but I didn’t because I don’t need one. The calculation to get the items was easy enough.

var dateRange = new DateRange(DateTime.Today.AddDays(-6), DateTime.Today);
foreach (DateTime date in dateRange)
{
    Console.WriteLine(date.ToShortDateString());
}

Output:

10/20/2009
10/21/2009
10/22/2009
10/23/2009
10/24/2009
10/25/2009
10/26/2009

Null Reference Exception on Instance Methods

Recently I was reading through a bunch of interesting blog posts. I was looking for information about the use of callvirt in C#. Callvirt can be used to call both virtual and non-virtual methods, and in fact is how all methods are called in C#. I don’t know how much of a performance decrease there is based on this, but I doubt it is much of one. I stumbled across this interesting post covering why C# uses callvirt from Eric Gunnerson’s blog.

We had gotten a report from somebody (likely one of the .NET groups using C# (thought it wasn't yet named C# at that time)) who had written code that called a method on a null pointer, but they didn’t get an exception because the method didn’t access any fields (ie “this” was null, but nothing in the method used it). That method then called another method which did use the this point and threw an exception, and a bit of head-scratching ensued. After they figured it out, they sent us a note about it.

We thought that being able to call a method on a null instance was a bit weird. Peter Golde did some testing to see what the perf impact was of always using callvirt, and it was small enough that we decided to make the change.

Now that certainly is odd behavior. I don’t know how I feel about it though. So basically one could have been able to call instance methods on null instances of an object as long as they didn’t access any members of the object itself. First I will say that methods with fewer dependencies are great.

So C# was of course adjusted to disallow this, but if it hadn’t then this could potentially work.

using System;
namespace NullInstanceMethod
{
    class Program
    {
        static void Main(string[] args)
        {
            Enrick brendan = null;
 
            Console.WriteLine(brendan.Awesome());
        }
    }
    class Enrick
    {
        public string Awesome()
        {
            return "Awesome";
        }
    }
}

 

Yep, that method isn’t static. It’s an instance method, but you would have been able to call it.

So to see that in action why don’t we disassemble this code and make the change directly to the intermediate language.

First we need to get the IL using ildasm, so open up the VisualStudio 2008 Command Prompt and type this command.

ildasm PathToTheExecutable /out:new.il

This will create a file “new.il” in our VS Command Prompt working directory.

Now we can open this in our favorite editor and we will see a bunch of code. We are just looking at this main method though.

.method private hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // Code size       16 (0x10)
    .maxstack  1
    .locals init ([0] class NullInstanceMethod.Enrick brendan)
    IL_0000:  nop
    IL_0001:  ldnull
    IL_0002:  stloc.0
    IL_0003:  ldloc.0
    IL_0004:  callvirt   instance string NullInstanceMethod.Enrick::Awesome()
    IL_0009:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000e:  nop
    IL_000f:  ret
  } // end of method Program::Main

See IL_0004 there is our callvirt that makes the call to our instance method. If we change that to a regular call we should be good.

Now we just put the IL back into the assembly.

ilasm new.il

And we execute it and here is the result.

CallSuccess

 

 

And there you have it. I just called an instance method on a null instance of a concrete class without getting a null reference exception? Strange? Yes. Wrong? I don’t know if it really is.

For your homework I would like you to consider what would happen if I were calling an interface’s method instead of a concrete class.

Fun With Web Forms Controls and LINQ

Since LINQ has come out I’ve been very fascinated with it. LINQ to SQL is kind of cool, but working with in-memory collections is my favorite. Sure anything we can do with LINQ we could have done before, but now it’s easy. While not exactly the most practical and certainly not the most efficient method of handling things, working with a page’s Controls collection can be a lot of fun.

So perhaps I want to change the text of all of the TextBoxes on a page. I can easily grab that collection like this.

IEnumerable<TextBox> textBoxes = Page.Controls.
    Where(c => c.GetType() == typeof(TextBox)).Select(t => (TextBox)t);

Well sort of except that some controls will not be in that collection because this is a tree structure so I’ll make a recursive method which will get me all of the controls on the page.

public IEnumerable<Control> AllControls(Control root)
{
    if (root != null)
    {
        if (root.Controls.Count < 1)
        {
            yield return root;
        }
        foreach (Control c in root.Controls)
        {
            if (c.Controls.Count < 1)
            {
                yield return c;
            }
            else
            {
                foreach (var control in AllControls(c))
                {
                    yield return control;
                }
            }
        }
    }
}

Now we can work with a page having nested controls. Fun eh? Here is how you can get all of those controls and set the Text property of TextBox ones to their own IDs.

IEnumerable<TextBox> boxes = AllControls(Page).
    Where(c => c.GetType() == typeof(TextBox)).Select(t => ((TextBox)t));
foreach (var textBox in boxes)
{
    textBox.Text = textBox.ID;
}

Try it out with a page with textboxes in a login view. It works. Enjoy. Have fun!

Viewing Disassembled IL with ILDASM

For those of you who are simply computer geeks I present to you an easy way to view the generated intermediate language code that is generated when you’re using the .NET Framework. So if you’ve ever wanted to see what is generated from your compiler, so you can see what code gets executed at run-time you just need to take a few simple steps.

Open up the Visual Studio Command Prompt. You can find this command prompt in the Start Menu inside of the tools folder for Visual Studio.

VS-Command-Prompt

From here you will be able to open up ILDASM’s graphical user interface. Open it by typing “ILDASM”. It’s a very simple program.

ILDASM-Start

From here you will want to open up the assembled file you want to view. This could be a class library or an executable. In this example I will use a “Hello World” console application.

ILDASM-Project-Open

The console application really only has one class. ILDASM_World.Program, which can be seen in the image. You can see the ILDASM_World namespace is where the class is located. Inside of the class we have a constructor (this is the default one I did not write the code for it). See this is neat, because we can see that a default constructor was created for us and we can see exactly what it does.

The Main method listed there is a standard one with a Console.Writeline(“Hello World!”); line written in it.

When we open up the method to view it we see the following IL is generated when we compile.

ILDASM-Main

Now what is really cool here is that I bet pretty much every person reading this can figure out exactly what that code is doing. I think that people could have figured it out without my having to explain it. It is really cool to see. There are a lot of awesome tricks you can see here. Also if you’re ever wondering what is going to happen when you compile something I recommend looking here. You’ll be able to see exactly what actually happens.

This will assist you when you’re writing your code since you’ll be able to make a more educated decision on which approach to take with your code if you see what will be generated behind the scenes.

Your homework is to try this with loops and with a goto.

Overloading Implicit Conversions with Generics in C#

Overloading operators in a language is an excellent tool in every developer’s tool belt. It allows us to design our code in ways feeling far more natural. For example if we didn’t implement operator overloading for addition of numbers we would have some strange code. Could you imagine if we still wrote this kind of stuff?

int x = 5;
int y = 4;
int z = x.Add(y);

When we teach addition the non-computer way we learn it as “5 + 4 = 9”. The language reverses things and we switch the expression into “9 = 5 + 4”, but this is no big deal since we’re still using our operators. Some things happen behind the scenes so often we really don’t even think about them. Implicit conversions of numbers happens all the time. If we have a method that returns an integer we can certainly assign that value to a double. Why? Since we don’t lose any information doing that conversion it is just able to happen. We know that it is easy to store an integer value in a double so it is allowed.

One thing that I’ve always loved about the Nullable objects in C# is their ability to trick many of their newer users. A lot of people really don’t know about Nullable objects. I think they are fooled by the type? syntax into thinking it is something special. When the only thing special is the syntax. Beneath the surface we are actually just using Nullable<type>. My favorite part about the object is that they were nice enough to overload the implicit conversion from your type T into the Nullable<T>. The nullable object is just a cleverly hidden use of C# generics.

If you use .NET Reflector to examine the code for their implementation you will see this method.

public static implicit operator T?(T value)
{
    return new T?(value);
}

 

Sure that seems kind of boring. This is basically like a constructor in that it creates a new instance of the Nullable type and accepts an object of type T. The power comes from the fact that the user doesn’t need to realize he is changing types. It lets us do this.

int regularInteger = 3
int? nullableInteger = regularInteger;

 

Now to make things a little bit clearer I will change how their operator works so we don’t use their “?” shorthand. We will qualify things in the code so it is clear how the generic is working for us.

public static implicit operator Nullable<T>(T value)
{
    return new Nullable<T>(value);
}

 

So now if you want to use this for your generic object you can do the same thing as above. All you need is a constructor for your object that takes in a value of T, and then you write this method with your class name instead of Nullable. There is one thing to keep in mind though. There is one thing that could catch you off guard if your generic object contains state. That is that using this operator will create a new object.

If your generic is being exposed using a property, Value, like with Nullable then you could just set Value equal to the object. That approach is not as elegant, so if you can avoid having to set the value of the Value property I recommend it.

You can also perform an implicit conversion the other way, but that can potentially lose information if your object has state. If it does not then it is safe to perform that one. To achieve it just switch things around so you have this instead.

public static implicit operator T(Nullable<T> value)
{
    return value.Value;
}

So have fun assigning objects to the implicitly-converting, generic objects.

If you have questions or concerns or you just plain think I am wrong. Tell me about it! :-)

Constructors Should Be Simple and Stupid

There are plenty of commonly known and upheld ideas about how software should be written. There are rules and guidelines professed by many developers which recommend following this design principle or that one. Some are more important than others. Some are easier to find and correct than others.

One such rule that I believe is important to follow is that all constructors remain simple and stupid. This is about as advanced as I believe a constructor should even be.

public SomeObject(int someValue, int someOtherValue, 
    ISomeKindOfInterface someKindOfInstance)
{
    _someValue = someValue;
    _someOtherValue = someOtherValue;
    _someKindOfInstance = someKindOfInstance
}

These are merely assignment statements which use the local variables (parameters). We never ever want to call methods in our constructors. This includes calling constructors inside of our constructor. There are very good reasons for this which I will explain in detail.

 

 

Reasoning for keeping constructors simple

It is difficult to test classes which do work in their constructors. When work is done in the constructor it becomes more difficult to manage the object. This is because the mere creation of an instance causes something to happen. This is difficult to handle in unit-testing because you’re trying to keep control of all aspects of the code while testing. Control is required in order to test effectively, because you need to be able to expect certain behavior to exist based on carefully controlled circumstances.

Otherwise dependencies are hidden. When we instantiate variables inside of a constructor we are “taking a dependency” on the object we are creating. By depending on that code we are limiting ourselves greatly because we are not able to inject anything else. We are not coding against an interface we are working with a concrete class that will be difficult to change or remove.

When we go to test it will be difficult to do so because of these dependencies which have been hidden away in our constructor. Classes should be honest with you. They should tell you up front what else they are dependent on. This honesty is given by having constructors which are open and giving information freely by asking for the dependent objects through constructor parameters.

Otherwise we are adding an extra responsibility. The Single Responsibility Principle is another commonly held principle that states than any object should have one responsibility. This is powerful because it means that any object should have only one reason to change. When we add code to the constructor we have given the object the responsibility for knowing how to construct the object graph for this type of object. If the object is complicated to construct then there should be something else with that responsibility.

What to look for

Keep your eye out for any and all method calls. If any code other than a field or property is being called from within a constructor this is bad.

Instantiation of other objects is a sure sign of a dependency. This goes for anywhere not just in constructors. If you have the “new” keyword it means you’re dependent on the object being created.

Any “logic” in the constructor. If there are conditional statements then you probably have something to fix.

More than a handful of lines is probably too many as well, and is a sign that the constructor is doing more than it should.

 

Example bad code

public SomeObject(int someValue)
{
    _myKindOfTown = new Chicago();
 
    if (someValue > 5)
    {
        _myKindOfTown.HandleMyKindOfRazzmatazz();
    }
}

How to solve the problem

Removing the Object Initialization

One of the easiest ways to improve things is to get rid of the object initialization from the constructor. Passing the values for these objects as parameters is how we get around the issue of initialization. This makes it so that we do not do the work in the constructor.

In some cases we know we will not use that object, for example in our tests, so we can pass in a NullObject.

This process is called Dependency Injection, and it allows us to “inject” our dependencies into our objects.

Create a class to handle the construction

If your object has some complicated requirements involved in the construction that need to happen every time the object is created, you should think about creating an object whose sole responsibility is to create these other objects. As we said earlier a complicated initialization task is another responsibility, so we can have an object who owns that responsibility.

These are often Factory classes who know how to build other objects.

Fixed Code

// Object creation method in another class
public SomeObject CreateSomeObject(int someValue)
{
    ITown chicago = new Chicago();
    if (someValue > 5)
    {
        chicago.HandleMyKindOfRazzmatazz();
    }
    return new SomeObject(chicago);
}
 
 
// ctor for SomeObject
public SomeObject(ITown myKindOfTown)
{
    _myKindOfTown = myKindOfTown
}

Overusing var in C#

With C# 3.0 came one new feature I both love and hate; the implicitly typed local variable: var. I think it is great because it is implicitly typed, but it is still strongly typed. At compile time it will be the explicit type as if you had typed the actual type name. Visual Studio is able to determine during development what the type is, so there isn't much of a downside. However, I believe it gets overused.

I think it is great if the line contains the "new" keyword, because I can already see the type name because it gets written for the constructor. Using "var" all the time really irks me though. It is inconvenient, because I can't always tell what type the variable is. This isn't always too much of an issue, but I prefer defining the type when possible.

For generics it is great since those type names get quite long. With generics we define two types together, so with longer names this sometimes becomes a little unwieldy. This is one of the great strengths of this new behavior in C#.

Earlier today I was reading an interesting post from Jimmy Bogard. He was blogging about The Filter-View anti-pattern. What bugged me about the post was his use of var. Now I know this has nothing to do with the actual post itself, but who can resist posting about their coding preferences?

In the post he had this code snippet.

public class ProductController : Controller
{
    [LoginInfo]
    public ActionResult Index()
    {
        var products = _productRepository.FindAll();

        return View(products);
    }

Now can you tell me what type is the variable products? Sure you might guess a collection of Product objects. You're probably right. Is it an IEnumerable? Is it an array? Is it a list? No, you don't know for certain. In fact you can't be sure it is a collection of Product objects. What if it were a collection of product names? That could be a badly named method and you get back strings.

You might think I am stretching a bit there on the strings, but there certainly could be methods which just didn't clarify well enough in there name. Now I know that I can mouse over the type in Visual Studio and instantly find out what type it is, but I should have to. In fact I probably wouldn't. I would probably try to use it and be kind of annoyed. Odds are I would have made an assumption on what type it is, and then I might have been annoyed when I tried to use Length thinking it was an array and then found our it was a List and I needed to use Count.

Anyway, I do recommend reading blog posts from Jimmy Bogard even though he overuses the implicitly typed local variable in his code snippets.

LINQ Your Collections with IEqualityComparer and Lambda Expressions

Anyone using LINQ to manipulate in-memory collections is probably also using plenty of lambda expressions to make things quite easy. These two additions were really meant for each other. One of our interns here recently ran into an interesting problem while using LINQ. As a relatively new user of .NET based languages, reference types caused him a bit of trouble.

The problem

While using the dot notation with lambda expressions, he was using the Except method in the following way.

List<MyObject> x = myCollection.Except(otherCollection).ToList();

Well the problem here is that these two collections contain "MyObject"s, and when it does the comparison it does so based on the reference. This means if those are separate but equivalent objects that the comparison will claim they are different.

He had unit tests making sure that the except statement worked, but was using the same instance of variables to Assert, so the tests claimed to work.

I told him the problem and mentioned that there was probably an overload of Except that allows one to specify how to do the comparison. I was correct, but the overload takes an IEqualityComparer object. I was hoping for a Func<x,x,bool> as the second parameter, so I did what I always do; I Googled to see if anyone knew an easy way to get that to work without doing extra work.

The Internet was kind enough to inform me that there was no built in way of handling this situation.

Building your own was the suggestion. It is a pretty simple class, so it can just be tossed somewhere to be reused easily. It could easily come up and be needed again.

public class LambdaComparer<T> : IEqualityComparer<T>
{
    private readonly Func<T, T, bool> _lambdaComparer;
    private readonly Func<T, int> _lambdaHash;

    public LambdaComparer(Func<T, T, bool> lambdaComparer) :
        this(lambdaComparer, o => 0)
    {
    }
    
    public LambdaComparer(Func<T, T, bool> lambdaComparer, Func<T, int> lambdaHash)
    {
        if (lambdaComparer == null)
            throw new ArgumentNullException("lambdaComparer");
        if (lambdaHash == null)
            throw new ArgumentNullException("lambdaHash");

        _lambdaComparer = lambdaComparer;
        _lambdaHash = lambdaHash;
    }

    public bool Equals(T x, T y)
    {
        return _lambdaComparer(x, y);
    }

    public int GetHashCode(T obj)
    {
        return _lambdaHash(obj);
    }
}

Now that we have a nice, Generic, comparer which can take lambda expressions, we are all set to plug this in to the previous code.

List<MyObject> x = myCollection.Except(otherCollection, 
  new LambdaComparer<MyObject>((x, y) => x.Id == y.Id)).ToList();

// or

IEqualityComparer comparer = new LambdaComparer<MyObject>((x, y) => x.Id == y.Id);
List<MyObject> x = myCollection.Except(otherCollection, comparer).ToList();

I admit I am still kind of annoyed that there wasn't an overload which just took a Func<T, T, bool> or a Func<T, T, int>.

Either way, I hope this helps someone use LINQ a little more easily. I know of some alternate ways of solving this same problem. So if you think I should have solved this differently then blog it and link back here or just post a comment below.

Update 16 April 2009 - From a comment below

One commenter below posted a suggested extension method for use with this. He suggests using this nice extension method so you can hide away the fact that you're using the custom comparer class.

public static class Ext
{
    public static IEnumerable<TSource> Except<TSource>(this IEnumerable<TSource> first, 
        IEnumerable<TSource> second , Func<TSource, TSource, bool> comparer )
    {
        return first.Except(second, new LambdaComparer<TSource>(comparer));
    }
}

Thank you for the comment. I like the idea. It will very nicely hide away the fact that a silly comparer is needed.

Just In Time Properties

Properties with backing fields can easily be null. I often see properties which check the backing field to see if it is null. This is commonly done with an if statement with one line of initialization. One way to get around this is to use the coalescing operator in C#. If we use this in combination with an expressions, which might be a method, we are able to easily handle this property with one line.

Here is an example of what I am talking about.

private SomeType _someObject;
public SomeType SomeObject 
{ 
    get 
    { 
        return _someObject ?? (_someObject = giveMeSomeObject()); 
    } 
}

Notice how short and concise this is. I am able to with one line which is very clear handle this common scenario. Sure it doesn't always match this exactly, but I see plenty of properties people write where they do something similar.

I think that is very elegant and a lot nicer than doing this older style.

private SomeType _someObject;
public SomeType SomeObject 
{ 
    get 
    { 
        if (_someObject == null)
        {
            _someObject = giveMeSomeObject(); 
        }
        return _someObject;
    } 
}

Converting an Array of Integers int[] to an Array of Strings string[]

I was working on a code snippet I plan to put into a blog post, and while writing it I needed to convert and array of integers to an array of strings. I try to think of a quick easy way to do this and none comes to mind. Well, I of course know that I could just loop through them and convert them from ints to strings, but that is really lame especially when I want the code to be small so I can put it in a blog post.

So there are a few options that present themselves when you are looking for a method to help you out.

  • Write your own method to solve the problem. (I try to only do this as a last resort. I try to use existing code when possible.)
  • Ask Google (or any other search engine) for answers posted on forums, blogs, articles, documentation, etc.
  • Go ask/search on a forum or a Question and Answer site.
  • Use intellisense and check some related classes which may hold the answer.

In this instance I used the last one. I checked out some classes using intellisense to see what methods were available. I was working with arrays, so the one I checked is the Array class. Array.ConvertAll is what I needed.

var intArray = new[] {1, 2, 3, 4, 5};
string[] stringArray = Array.ConvertAll(intArray, i => i.ToString());

That is roughly how I am using it in my code. Notice the nice lambda way of handling the individual object conversion. You can also solve the problem using a full-fledged method call. I just chose this to keep things more compact.

Here is an example using a method to hide the lambda and do the conversion.

static void Main()
{
    var intArray = new[] {1, 2, 3, 4, 5};
    string[] stringArray = Array.ConvertAll(intArray, IntToStringConverter());
}

private static Converter<int, string> IntToStringConverter()
{
    return i => i.ToString();
}

As usual there are still many other ways to do this, but I'll show you one that just has way too much unnecessary code.

I don't recommend using this example since it really just specifies way more than it needs to. I am just including this to illustrate the many ways to have solved this problem using this same method.

static void Main()
{
    var intArray = new[] {1, 2, 3, 4, 5};
    string[] stringArray = Array.ConvertAll<int, string>(intArray, 
        new Converter<int, string>(IntToStringConverter));
}

private static string IntToStringConverter(int n)
{
    return n.ToString();
}

Why don't I really like that one? Well to be honest I intentionally made it bad. The "new Converter<int, string>()" part is completely useless. You can remove it completely and the code still works, because we specified already that we are doing int to string. We alternatively could have removed the first <int,string>.

Although if I were using an older version of C# I would be forced to use the last one, or I could also use a combination of the second and third one.

Well, we're out of time here today. I hope you've enjoyed this edition of Finding Stuff Using Intellisense. This is your host, Brendan Enrick. We've been glad to have you with us today. Join us next time when we....  Find Stuff Using Intellisense. {queue the ending theme music}