.Net 3.5 Extension methods are a great new way of adding functionality to an existing
type – even a type you don’t have the source code to such as is the case with a
.Net framework library type i.e. String.
Suppose you had a string and wanted to see if that string existed in
another array of strings. You can write your own loop to search, or you
could write an extension method which would do it for you. A method with the signature of bool IsInArray(string textToFind , string[]
textArray) would appear to accomplish such a goal. We can add such a method to the string type
with C# 3.0 and the .Net Framework 3.5.
It isn’t completely obvious how this works so I’ll provide some clarification. First of all, your extensions must be defined
in a separate class and the namespace must be referenced in your code. In this case we’d include a “using ExtensionMethodSample”
statement to get access to StringExtensions. Secondly, examine the signature of the IsInArray method. The first parameter is “this string myString” which tells the compiler the method is an
extension of string. An argument isn’t explicitly passed to the method for myString, but the parameter can be used
within the method as if it were. Parameters
2…n are all explicitly supplied with arguments as you’ll see with Intellisense.
If we were
to execute this call to IsInArray(this string myString, string[] stringArray),
passing in the myStrings string array, we’d receive the Boolean value of True
back because “hello” was in the myStrings array.
Gotchas
This appears
to be a very promising way to add functionality to existing types however there
are some “gotchas”:
Signature Ambiguity (or lack thereof)
If you
provide an extension method with the same signature as a method already
available on the type you’re extending, the extension method is ignored. Instead, you should create your own type
derived from the type you’d like to extend and override the method or add an
overload. An example of this if you
create an extension method of signature “string ToString()” for type
String. String already has a “string
ToString()” method which would be the method called.
I did find I can create an additional overload
of an existing type as an extension method.
Let’s take this same ToString() example.
If I added an overload which doesn’t yet exist for ToString() such as
“public static string ToString(this string myString, int repeatCount)” then I’d
have the base ToString() methods plus my new overloaded ToString method.
Type Modification
If the type
you are writing an extension method for changes, your extension method may
require modification to maintain compatibility.
This sort of goes without saying and is just as likely to be the case if
you’ve derived a class from that type and added methods to your new class.
Conclusion
As stated,
Microsoft’s recommendation is to derive a class if possible and avoid extension
methods. I personally feel extension
methods have their place with primitives and potentially asp.net built-in user
controls. These are types I just don’t
want to derive from and modify – I prefer the built-in ease of use. I’ve longed for a method on a checkbox list
which returns a collection of items which were checked. Instead we must loop through the checkbox
list and build our own collection. An
extension method can resolve this issue for us without creating a completely
new asp.net user control.
I’m sure we’ll see extension method libraries
entering the community which provide often desired functionality not yet built
into the .net framework and C#.
For more information on extension methods, check out Scott Guthrie's blog article on .Net Framework 3.5 extension methods.
For other great C# 3.0 information, visit Ian Suttle's Blog.
|