As with all things in .Net 2010 there are people discussing and implementing technologies with varying degrees of intelligence and success. Extension methods were created to solve a specific problem and I expect to see some evolving patterns surrounding them. In general, if your implementation aligns with that purpose without creating even more development nightmares, then I applaud you. Much of the new technology from Microsoft is exciting but understanding the reasons behind the creation of a feature should come before its adoption into our patterns and practices.
In the IntelliSense below you will see several methods with a new symbol (a blue down-facing arrow). This symbol indicates that the associated member in the list is not actually defined in the containing class but rather it is defined elsewhere. Such methods are referred to as extension methods and become directly invocable for a type just as if they were natural members. This extension of a types’ members is done without extending the original class in the traditional sense. That is to say we don’t modify the original type nor do we utilize inheritance.
The following picture shows the new String type has several extension methods that are new to .Net 2010.
Creating extension methods is rather simple and quite frankly, the reason it has the potential for overuse or misuse. In the following example, I’ll show you the correct syntax for implementation but a simple example of misuse as well.
What is wrong with this leads me to what is hopefully an obvious best practice…your extension methods should do something that the class cannot already do. Let’s see how this looks in respect to the String now. When we go back to our string variable after adding the previous extension method we now see LetterCount in the drop down member list:
Being that it is called an extension method, if we already have a Length method, adding LetterCount is a little pointless. WordCount is a common extension however and would be acceptable as such.
Excessive use of these extensions to common types can render other libraries inoperable that depend on these types. When two libraries offer the same extension method name for a type they cause a compilation error that isn’t all that obvious as you can see here:
Extension methods should be kept to a minimum. If they are used, they should be used with the understanding that naming collisions can be quite common for common types as the names cannot be distinguished using namespaces. Distributed libraries should take great care to avoid using extension method names that may conflict with other libraries your customers may have created or adopted. A simple option might be to ensure a naming convention that you hope will avoid such conflicts but this will most likely cause a deviation in other coding standards.
You may have noticed the influx of functional programming into Microsoft technologies that carries a promise of side effect free methods. Keeping that in mind as a goal, when creating extension methods, one of my strongest feelings about these types of methods is that they should be completely side effect free.
The discussion I’d love to see come from this would be from my colleagues out there that that have already mastered FxCop now known as simply as Code Analysis (for rule enforcement in TFS). Extension methods are very useful in the right hands but I wonder …if it is possible to create a rule to perform either of these: stop someone from submitting an extension method against a particular type such as String or far more importantly, to ensure that an extension method does not create or alter state within the type that it extends.
I would love to hear your thoughts?
Bruce Barstow, .NET Technology lead and Senior Instructor, QuickStart Intelligence