Avoiding Extension Methods

Over the past couple months, we’ve been playing more and more with C# 3.0, .NET 3.5 and Visual Studio 2008 (man, it’d be nice to get these version numbers synced up). At first I was naively optimistic about the usefulness of extension methods, but in practice, they seem to add no real value and, on occasion, decrease readability.

The C# specifications themselves point out this flaw:

“Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible.”

(Interestingly, I couldn’t find the same such warning for VB.NET – maybe I was just looking at the wrong document).

I understand that extension methods were required for LINQ, but I haven’t come across, nor am I able to think of, a situation in which it’ll ever be necessary for me to use. Open classes have been a small stumbling block for Java/.NET programmers doing the switch to Ruby, and I see extension methods as a poor-man’s implementation of those.

In the end, like with anything else, it comes down to responsible and proper use. With or without extension methods, a bad programmer will write un-maintainable code. However, I do wish that the countless blogs and articles covering the new Orcas features, like extension methods, would do more than show-off the syntax and pump out a few examples. Explaining shortcomings, pitfalls and proper usage is more important than shallow examples.

For me though, I’ll stick with my explicit procedural StringUtility class.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

12 Responses to Avoiding Extension Methods

  1. Kaveh Shahbazian says:

    A bad programmer can blow-up the system with a single line of garbage Haskell too! Haskell is great but errors and bug are always there. We have not the problems that we encounter today, say 5 years ago. Whos knows what are the problems 10 years later and what will be the definition of “bad code”!

  2. FYI, the text that you quoted does not exist in the final C# specification that was released on Aug. 21st. You can always get the latest specification here:


  3. Jeff Handley says:

    My team builds software that is running most of the schools in the state of Ohio. And when I first heard of extension methods, the first thing I thought of was the following pseudo-code:

    DateTime dayOfAbsence;
    // get day of absence from user entry

    if (!dayOfAbsence.IsSchoolDay(mySchoolId))
    // show the user an error stating that the date entered is not a school day

    Of course this concept could equally be used for adding an ‘IsBusinessDay’ method that uses business logic to determine if the date value is a business day. Another method for ‘AddBusinessDays’ could be added too.

    The question that is yet to be answered for these approaches though is whether or not these extension methods would be intuitive for new team members.

  4. Lukkha Coder says:

    Another real life example: I have a method that takes the line schema for a comma delimited string and hydrates an object with the values from the string. I added it as an extension method to the string class.
    An example of how I invoke it:
    delimitedLine.Hydrate(lineSchema, objectToHydrate);

  5. Tim says:

    Hmmm – this kind of construct has been available in Smalltalk a long time and its very useful – particulary for visitor patterns where you want visit a diverse set of objects and perform a polymorphic operation.

    I haven’t had a chance to play with it in C# but I wonder if the stricter typing is what makes it less useful to you(as interfaces are strict and you are essintially trying to widen the interface of diverse objects – or make them compatible with some useful interface eliminating typeOf case constructs).

    It would be cool if you could do the above – it really can simplify programming and eliminate lots of wrapper objects.

    I have also seen this construct used in dynamic languages to add UI behavior to model objects (but before you scream – its done in an orthogonal manner – the model is left pure and a seperate namespace adds the additional methods for things like font, or colour or menu item which the UI layer can then rely on without have to add all kinds of extra decorators or level of indirection which can complicate things). Again not sure if these apply to you guys but food for thought.

  6. in most cases is more of a preference matter and a “nice to have” feature, nothing you couldn’t do in a different way, but most features are that anyway, the problem is with the (ab)use of it

  7. Ryan Haney says:

    I agree with Don. Extension methods are great (necessary?) for functional programming.

  8. Don Demsak says:

    You are correct. If you think like a procedural programmer, then yes, Extension Methods are a waste. But, if you adjust your mindset to more of a functional programmer, things like Extension Methods make more sense. It isn’t an easy task to unlearn the old habits of procedural programming, and I don’t think there will be a large number of Extension Method developers out there. But, when you grok them, you can do some incredible things (like the Query stuff in 3.5).

    There are lots of domains where you think verb first, and not object first. My guess is that the Transformation space is the next area to take advantage of the functional programming additions to .Net.

  9. Craig Bowes says:

    I don’t see how i would use them at all, ever. It seems like i need that kind of dynanism, i’d go for the ruby implementation like you said.

  10. Jim Wooley says:

    I repeatedly make it a point to demonstrate how using extension methods allows you to easily shoot yourself in the foot if you are not careful. See my post from a year and a half ago regarding this http://devauthority.com/blogs/jwooley/archive/2006/04/27/893.aspx. Then again, I did go off the deep end showing how to simulate extension members through extension methods recently as well. (see http://devauthority.com/blogs/jwooley/archive/2007/09/06/76005.aspx).

    As for the issue with the warning in C# and not VB, realize that VB does make extension method discoverability easier as it adds the “Extension: “descriptor as part of the intellisense tooltip which helps a bit.

  11. cmyers says:

    Scott Bellware made a good suggestion that, if you have to use them, make sure to put them in a namespace that’s explicit. While not as immediately obvious as ‘StringUtility’, seeing a using statement like:

    using Foo.Bar.ExtensionMethods.String;

    is a fairly big clue.

  12. “but I haven’t come across, nor am I able to think of, a situation in which it’ll ever be necessary for me to use”

    I’ve hit a couple things lately where I think extension methods would be nice. DSL development, Fluent Interface extension, BDD style testing come to mind.

    It might be worthwhile looking at some Objective C writings to see what they use this kind of thing for. They’ve had this feature for something like 15 years.