Have you ever had a moment while working with the .NET Framework when you thought, "Hey, they forgot a method in this class!"  For me, that was in the beta for 1.0 when I was working with a lot of delimited text.  The String class had a nice Split() method, but the method only accepted a single character as the delimiter.  Why in the world would anyone ever use more than a single character to delimit text?  Oh, wait.  What about quoted strings?  There are other possibilities as well.  So I was forced to explore the possibility of extending the String class.  Should be simple enough, just inherit from String and off we go.  Then I discovered the sealed keyword.  If I wanted to extend string now, I would have to wrap every string method and property in another class and add my own Split method to that.  On second thought... nah.  Too painful.

I sure wish C# 3.0 had been around in those days - or is that an oxymoron.  Maybe, kind of.  But it sure would have been good to have Extension Methods back then.  I've read about extension methods in C# 3.0 more than once, but it never really dawned on me how something like this could be used until the other day, and then I realized a few ways it could be useful.  So how do you add the functionality into a sealed class that MS forgot?  Like so:

namespace TestProject1
{
    public static class Extension1
    {
        public static string[] Split(this string theString, string theDelimiter)
        {
            //...functionality goes here.
        } 
    }

    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void SplitTest()
        {
            Assert.AreEqual(3, "My--three--words".Split("--").Length);
        }
    }
}

Simple enough.  I know, MS fixed it in a later framework, but it was a pain at the time.  And before you say, "You could have fixed this with a utility class Utility.Split(myString, myDelimiter)."  Yes, that's what I ended up doing in those situations, but it sure isn't as clean as saying String.Split().  String should have control over its own fate, not be imposed upon by utility classes - at least it should look that way.  "Looking the way it should" has something to do with Domain Specific Languages.  Essentially with Extension Methods you could code something that is immensely more readable and closer to your target domain than the general language or framework.  For example, if your particular target domain often needs to calculate a certain amount of time-lapsed, then it could be done like: 20.Minutes().Ago().  That's very intentional and much more readable than DateTimeUtil.CalculateTimeInPast(TimeSpanUtil.ToMinutes(20));

namespace TestProject1
{
    public static class Extension2
    {
        public static TimeSpan Minutes(this int numMinutes)
        {
            return new TimeSpan(0, numMinutes, 0);
        }

        public static DateTime Ago(this TimeSpan duration)
        {
            return DateTime.Now.Add(-(duration));
        }
    }

    [TestClass]
    public class UnitTest2
    {
        [TestMethod]
        public void DomainSpecificLanguageTest()
        {
            Assert.IsTrue(20.Minutes().Ago() < DateTime.Now);
        }
    }
}

Full disclosure: I didn't come up with the 20.Minutes().Ago() example, I think I heard it from Scott Hanselman, though I didn't grok it at the time, not until I saw Extension Methods one more time. I'm going to start looking at problems like this with a fresh set of eyes now.