Extension methods is a powerful feature that should be used when it´s really an extension on a type (like a string) that you would use over and over again. In contrast, a utility method is something you need once and performs something that is very specific to the problem you´re trying to solve, thus not considered an extension to a common API (like SharePoint for example).
With that said, one of the drawbacks of extension methods is that (at least nowadays without any special 3rd party tool) in order to use them you need to include the namespace to the class that holds the extension method/s (i.e. a using statement in C#) and of course reference the assembly that the extension/s lives in. In short VS doesn’t´t include any discovery service for extensions methods…yet
Consider the following extension method, WriteToConsole:
It lives in the StringExtensions class inside the namespace MyLib.Extensions (not a very uncommon kind of namespace right?) and let´s imagine that the extension resides inside the MyLib assembly.
Developer A, who wrote that extension, now decides to use it in some place in the application that developer A together with developer B (and other team members) are writing so developer A makes a reference to the assembly MyLib and adds a using statement to the top of the program:
Now, developer A can use his “excellent” extension to the string type!!
In some other place in the application developer B is writing a similar kind of code (OK, I know the example is not very real life but you get the point) but since developer B doesn’t´t know that developer A has written this extension (from the MyLib.Extensions namespace) developer B doesn’t´t know that in order to use it developer B needs to include the namespace MyLib.Extensions to use the extension that developer A wrote earlier.
Well, what if developer A had used another approach when writing that extension, e.g.:
Say what? namespace System…what´s up with that?
Developer A uses an approach where developer A is using the same namespace as the type that developer A is extending (i.e. string resides in the System namespace)
Now, when developer B writes the code using a string developer B will not need to include any special using statement to use the extension for the string type called WriteToConsole. They magically appear in the intellisense as an extensions (given that the MyLib.Extensions dll was referenced…but that was already taken care of by developer A)
But what happens if
The only downside to this approach is if the following situation occurs.
Say that developer B decides that the WriteToConsole (located in a file called developerAExtensions.cs) extension is a bit complicated and decides to write a simpler one…e.g.:
This extension, WriteHello, is in different file(developerBExtensions.cs) but has the same class name (StringExtensions) in the same assembly (MyLib.Extensions) and the namespace is still System. What will happen now?
When compiling, VS will give developer B an exception that indicates that the System namespace already contains a definition for StringExtensions (which is the name of the actual class…not the filename of the .cs file)
Note: This wouldn’t´t be an issue if the two extensions where located in different assemblies or if the class names where different
They way to solve that situation is
Make the classes partial, e.g.:
The complier will now “merge” those two classes into one StringExtensions class.
When writing extension methods, one way to avoid confusion on how to discover them is to use a namespace that match the actual type that you are extending (e.g. if extending string which is in the System namespace use System as your namespace for the extensions for the string type).
That way users of your extension methods won´t need to add any usings (imports in VB) to discover them.