Extension methods initially were used for those classes where we did not own the source code for. But nowadays we are using them increasingly for types where we do own the source.
This post aims to have an in-depth look at the place of extension methods in the API design.
As you have probably guessed, defining the extension method for
object type will cause the boxed integers objects to be compared instead of integers themselves and they surely won't be equal. So a generic implementation will solve the problem:
public static bool IsIn<T>(this T item, params T[] list)
{
if (list == null || list.Length == 0)
return false;
return list.Any(x => EqualityComparer<T>.Default.Equals(x, item));
}
Reality is, extension method only gives the illusion of method being on the type and what is being compiled is nothing but a plain old static method call. Having a look at the IL generated confirms this:
IL_0056: call bool ConsoleApplication1.ExtensionMethods::IsIn<int32>(!!0, !!0[])
ExtensionMethods above is the name of the static class I created for this method.
So extension methods are basically the same utility or helper static methods we have been writing only glamorised to look like instance methods. Yet they have the additional benefit of:
- It leads to much more readable and natural code.
- I do not have to know the name of the helper class whose static methods I am using - in fact the behaviour has nothing to do with the static class. That class is not really a class in a true sense since it does not exert state or behaviour. And that is why it has to be declared static: to make clear its design intentions.
- Fluent API can be easily designed for older types without touching them.
- Since it is not really an instance method call, it can be called on null instances. This is a desirable side effect since we can check for nulls in the extension method and cater for them (none of the "object reference not set to an instance..." nonsense!)
- Since it can be called on null instances, some type information for the null instance can be determined in the extension method (although it can be a base type or an interface) while this is not possible for a null object.
Extension methods when we do not own the type
This has been the typical scenario. We always wonder if for example
string had a such and such method and there was no way to achieve this. Now using extension methods we can. This scenario can also apply to cases where a historic API has been released (and you
own the API) but cannot be changed. In this case, your API can be enhanced using extension methods.
With such usage, there is no decision to be made hence the design has already been done. Extension methods serve mere as a nice utility and syntactical sugar.
One of the most useful use cases I have found is the function composition in functional programming in C# (see some examples in my other posts
here and
here). This is especially important since you can achieve readability by method chaining. For example:
usingReflection
.Repeat(TotalCount)
.OutputPerformance(stopwatch, performanceOutput)();
In addition to the examples above, let's have a look at a simple example to swallow the exception and optionally log the error (note how the implementation reuses itself to swallow errors that could arise from logging):
public static class WrapSwallowExtension
{
public static Action<T> WrapSwallow<T>(this Action<T> action, Action<Exception> logger = null)
{
return (T t) =>
{
try
{
action(t);
}
catch (Exception e)
{
if (logger != null)
logger.WrapSwallow()(e);
}
};
}
}
So I can use:
string myString = null;
Action<string> action = (s) => { s.ToLower(); }; // reference null exception!
action.WrapSwallow()(myString); // swallowed
Now here I created a new exception but when I am working in a functional scenario, I already have my actions and functions.
Extension methods when we own the type
I have heard some saying "Why would you wanna use an extension method when you own the code? Just add the method to the type."
There are cases where you own the type yet you would still use an extension method. Here we have a look at a few scenarios below.
Extension methods for interfaces
This is the most obvious use case. Most of the Linq library is implemented using extension methods (while Microsoft owns the types). An interface cannot have the implementation but you can use extension methods to add implemented enhancement to your interfaces.
Without getting into the debate whether implementing
ForEach against
IEnumerable<T> is semantically correct or not (don't! I am not going there) you might have noticed that the function only exists for the
List<T> so you have to use
ToList() to use the feature. Well, this can be easily done for IEnumerable<T> too:
public static class IEnumerableExtensions
{
public static IEnumerable<T> ForEachOne<T>(this IEnumerable<T> enumerable, Action<T> action)
{
foreach (var t in enumerable)
{
action(t);
yield return t;
}
}
}
In this particular example, I do not own the source for IEnumerable<T> but even if I had, I would only be able to
associate implementation with the interface using extension methods.
Overloading
This is the next common case. If you are familiar with ASP.NET MVC, you probably have noticed that the most of the functionality of
HtmlHelper class has been implemented using extension methods.
Html.TextBoxFor(x => x.Name)
In fact all different overloads of HtmlHelper for Textbox, RadioButton, Checkbox, TextArea, etc are implemented using extension methods. So the HtmlHelper class itself implements a core set of functionality which will be called by these extension methods.
Now lets look at this fictional interface:
public interface IDependencyResolver
{
object Resolve(Type t);
T Resolve<T>();
}
The interface has two methods for resolving the type, one using the generic type the other with the type instance. Whoever implements this will be most likely implementing the non-generic method and then make generic method call the non-generic one:
public interface IDependencyResolver
{
object Resolve(Type t);
}
public static class IDependencyResolverExtension
{
public static T Resolve<T>(this IDependencyResolver resolver)
{
return (T) resolver.Resolve(typeof (T));
}
}
This will help to:
- Trim down the interface and make it terser so it can express its design intentions more clearly
- Save all implementers of the interface having to repeat the same bit of code
When I look at the interface
IQueryProvider, I wonder if it was designed before extension methods were available:
public interface IQueryProvider
{
IQueryable<TElement> CreateQuery<TElement>(Expression expression);
IQueryable CreateQuery(Expression expression);
TResult Execute<TResult>(Expression expression);
object Execute(Expression expression);
}
So the 4 methods could have been reduced to 2. Considering the fact that Linq and extension methods both came in .NET 3.0, my suspicion seems very likely!
Dependency layering
Another case where you might decide to use an extension method rather than exposing a direct method on the type is
when a type's sole dependency on another type is confined to a single method. This is very common in cases where the dependency is on a layer above the dependent type - while naturally must be the other way around.
For example, let's look at this case:
// THIS WILL NOT WORK!
// sitting at entity layer
public class Foo
{
// ...
public Bar ToBar()
{
// ...
}
}
// sitting at business layer
public class Bar
{
// ...
}
Now in this example, I have laid out these two classes in different logical layers to better illustrate the case - but it does not have to be, this is all about managing dependencies, in the same layer or other layers. We have baked in
Foo's the dependency to Bar for the sake of
ToBar(). The solution is to create an extension method for the
ToBar().
So we can write (and completely
decouple to classes):
public class Foo
{
}
public class Bar
{
}
public static class FooExtensions
{
public static Bar ToBar(this Foo foo)
{
return new Bar();
}
}
Providing implementation for enumerations
This is one that probably many of us have done. Enumerations - unfortunately - cannot contain implementations so extension methods are a good place to put the implementation code for enums. This is usually to do to conversion, parsing and formatting.
Delay decision on API signatures
With regards to an API, anything that goes into the public interface of the type is difficult to change. As such attempting to provide all possible overloads and use cases of the type on its public interface is likely to fail.
Delaying such decisions with providing a base functionality on the type and then providing more and more extension methods with each release is a useful process. ASP.NET team have used this technique for ASP.NET MVC and recently with ASP.NET Web API.
Drawbacks
Extension methods are static methods. As such they cannot be mocked using standard mocking frameworks.
An extension method should not have any dependency other than the ones passed to it.
Let's look at this case:
public class Foo
{
public string FileName { get; set; }
public void Save()
{
// ...
}
}
public static class FooExtensions
{
public static void SafeSave(this Foo foo)
{
var directoryName = Path.GetDirectoryName(foo.FileName);
if (!Directory.Exists(directoryName))
Directory.CreateDirectory(directoryName);
foo.Save();
}
}
In this case, unit testing any class that uses
SafeSave becomes a nightmare. What we need here is to create an interface
IFileSystem and pass along with the extension method to abstract it from using the real file system.
Conclusion
Availability of extension methods has changed the way we design software APIs in the .NET world. We have started to build the basic functionality in the actual types and use extension methods to provide overloading.
There are 5 reasons to use extension methods when you own the type:
- To associate implementation with interfaces
- Overloading of an API
- Removing dependency especially in logical layering
- Providing implementation for enumerations
- Delaying decision on API signatures
An extension method should not have any dependencies other than the ones passed to it.
