.net - with - why we use extension method in c#

What are the best practices for using Extension Methods in.Net? (6)

I have seen these being used every which way, and have been accused of using them the wrong way (though in that case, I was using them that way to demonstrate a point).

So, what do you think are the best practices for employing Extension Methods?

Should development teams create a library of extension methods and deploy them across various projects?

Should there be a collection of common extension methods in the form of an open source project?

Update: have decided to create an organization wide extension methods library

Eric Lippert has blogged about this and I suspect I can't do much better than to quote him:

So, yes, the oft-heard criticism that "extension methods are not object-oriented" is entirely correct, but also rather irrelevant. Extension methods certainly are not object-oriented. They put the code that manipulates the data far away from the code that declares the data, they cannot break encapsulation and talk to the private state of the objects they appear to be methods on, they do not play well with inheritance, and so on. They're procedural programming in a convenient object-oriented dress.

They're also incredibly convenient and make LINQ possible, which is why we added them. The fact that they do not conform to some philosophical ideal of what makes an object-oriented language was not really much of a factor in that decision.

I would add, however, that they're useful beyond just LINQ - for the same reason that they're useful in LINQ. It's really nice to be able to express algorithms which work on arbitrary implementations of a particular interface (such as IEnumerable<T> in LINQ to Obhects). Such algorithms typically don't have any context beyond the interfaces you're working on, so they're often naturally static.

If you accept that you've got some static utility method, which syntax would you rather use?

// Traditional

// Extension methods

The latter is simply more readable in my opinion. It concisely expresses what you want to do. It doesn't make it clear how you want to do it, but that's less important for most of the time - and more important when you're debugging that particular line, of course.

The upcoming release of the Framework Design Guidelines, 2nd Edition will have some guidance for implementing extension methods, but in general:

You should only define extension methods "where they make semantic sense" and are providing helper functionality relevant to every implementation.

You also should avoid extending System.Object as not all .NET languages will be able to call the extension method as an extension. (VB.NET for instance would need to call it as a regular static method on the static extension class.)

Don't define an extension method in the same namespace as the extended type unless you're extending an interface.

Don't define an extension method with the same signature as a "real" method since it will never be called.

There are two parts to it.

  1. Is it OO when we use it No; it makes you feel that you are calling method on the particular type

  2. Is it OO based on how it is compiled/built

Yes; Compiled code has a static method using the object on which extension method was invoked

Are extension methods an object-oriented feature of C#?

Extension methods are not an object oriented language feature. (compared to: classes, inheritance, polymorphism etc).

Like every language feature, it should be used where it is appropriate and for what it is designed for. There are already dozens of questions about when and how to use Extension methods.

Extension Methods vs. Regular Methods - Best Practice Ideas

Use an extension method if any of the following conditions are true:

  • You need a method on a type and you don't own the source.
  • You need a method on a type, you do own the source, and the type is an interface.
  • You need a method on a type, you do own the source, but adding the method creates undesired coupling.*

Otherwise, you should use a real method on the actual type itself.

I don't think it makes a whole lot of sense to create an extension method for a class or struct that you own the source for - why confuse readers with an extension method when a regular method will suffice?

Suggested reading: Framework Design Guidelines: Extension Methods

* Imagine that you wanted to add convenience methods to a type but don't want to create dependencies to assemblies or types that shouldn't be part of the API. You could use extension methods to manage this.