Mircea Trofin has some design guidelines with regard to some C# 3 language additions (that I assume will make it into a revised Framework Design Guidelines of some sort). They more less agree with the guidelines I published in Code Magazine a while ago. There are some slight differences:
Consider using extension methods in any of the following scenarios: to provide helper functionally relevant to every implementation of an interface… and,
Do define extension methods in the same namespace as the extended type, if the type is an interface, and if the extension methods are meant to be used in most or all cases. This applies to framework designers that are publishing interfaces but also want to publish callable methods that apply to all implementation of those interfaces. My article approaches the guidelines more from a non-framework designer. I do agree that extension methods to extend interfaces is very useful and is probably one of the most adept use of extension methods. Although, I think the wording of this guideline could use improvement.
Avoid defining extension methods on System.Object, unless absolutely necessary. Good advice.
Do not define extension methods pertaining to a feature in namespaces normally associated with other features. Instead define them in the namespace associated with the feature they belong to, or a namespace of it. This is really unclear (and seems to suggest contradicting the first guideline: Avoid frivolous use of the extension methods feature when defining methods on a new type. Use the canonical, language-specific means for defining type members). I’m assuming the jist of this is, as a framework designer, don’t arbitrarily put extension methods in the namespace of the type the method applies to, consider putting the extension method in a more applicable namespace, if possible. For example, if you want to declare an extension method “Forward” for Telecom.INode implementations, putting the method in a “Routing” namespace would be better than arbitrarily putting it in the “Telecom” namespace. I’ve changed the Mircea’s guidance slightly to use a interface in the example–which I think makes it more clear.
Mircea also includes Consider using extension methods in any of the following scenarios:… when object model considerations would dictate taking a dependency on some assuming but taking such a dependency would break dependency management rules. This means, should you need to add a method to a class but adding that method would create cyclic dependency or would cause a lower level assembly/class to be dependant on a higher level class, break the method out into another assembly as an extension method. Use this advice with caution; I would argue that if you think you need a method like this at all (even if implemented as an extension method), you likely have some design problems and should only be considered when revising a published framework, and not when creating a new framework.
Another tidbit of guidance that came about after I wrote the article and Mircea doesn’t mention is that extension methods can make writing fluent interfaces much cleaner by separating the state management concern of supporting a fluent interface from the class that it applies to.
Thoughts? Any additional guidance you feel has been overlooked (with regard to extension methods and LINQ)?