Upcoming C# 3 Guidance From Microsoft

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)?

kick it on DotNetKicks.com

6 thoughts on “Upcoming C# 3 Guidance From Microsoft”

  1. I do use a few extensions on object:

    [Conditional("DEBUG")]
    [DebuggerHidden]
    [DebuggerStepThrough]
    public static void CantBeNull(this T obj) where T : class
    {
    Debug.Assert(obj != null, “Object of type ‘” + typeof(T) + “‘ can’t be null.”);
    }

    So I don’t have to write Debug.Assert everywhere.

    public static V Maybe(this T instance, Func func) where T : class
    {
    return instance != null ? func(instance) : default(V);
    }

    string test = null;
    int length = test.Maybe(t => t.Length); // length is 0 :)

  2. My two cents:

    1- Define extension methods only for interface types defined by yourself.

    Extension methods on third-party classes introduces risks with versioning. And extension methods on your own classes don’t make any sense.

  3. Ian:

    My post addresses the exact question of if extension methods on your own classes make sense.

    There are valid uses … namely to provide context sensitive information.

    For these types of uses my vote is to ALWAYS put these extension methods in the namespace where the builder actually lives ex:

    MyDll.Messages.Fluent

    Cheers,

    Greg

  4. Hi,

    Could you please let me know whether there is any C# 3 book available that explains about how to implement SOLID principles (Open Closed Principle,DI,Likosov, etc) using language features like GENERICS, LINQ, Lambda Expression,etc.

    –Sorry if it is a wrong place to ask this question as this is a deviation from the topic.

    Thanks
    Lijo Cheeran Joseph

  5. @Lijo: I don’t know of any books that specifically associating language features to SOLID principles. There’s a couple of books that have information about SOLID principles (among other things) and C#. Some of the principles would inherently require specific language features (like DI and Generics):

    Robert/Micha Martin’s Agile Practices and Patterns in C#: http://www.amazon.ca/Agile-Principles-Patterns-Practices-C/dp/0131857258
    Karl Seguin’s free Foundations of Programming eBook: http://bit.ly/2BWCfd

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>