Extension Methods

Command Connection Points and Exception Handling Reloaded

Dennis "D.C." Dietrich — Mon, 09 Jul 2007 17:25:42 GMT

In Debugging of and error handling for synchronous Commands I explained why you can't handle exceptions

re: Extension Methods

DKE — Fri, 06 Jun 2008 13:23:59 GMT

If I get this right, the ability to implement extension methods on interfaces introduces some kind of (low-level) multiple-inheritance feature. You can implement extension methods for, say, two interfaces and let a certain class implement these two interfaces. Afterwards you have a class which is able to execute all(!) extension methods. Has nothing to do with functional programming, but really interesting in some way... What do you think about it?

using System;

namespace MultipleInheritance

{

public interface I1 {}

public interface I2 {}

public static class MyExtensions

{

public static void Do1 ( this I1 obj ) { Console.WriteLine ( "Do1" ); }

public static void Do2 ( this I2 obj ) { Console.WriteLine ( "Do2" ); }

}

public class MyClass : I1, I2 {}

class Program

{

static void Main ( string[] args )

{

MyClass obj = new MyClass();

obj.Do1();

obj.Do2();

}

re: Extension Methods

EricWhite — Fri, 06 Jun 2008 19:36:55 GMT

@DKE,

Your point is interesting. However, with multiple inheritance (MI) in C++, there is a different abstraction - MI means that a class has an 'is a' relationship to both of its parent classes. The encapsulation semantics are different - a MI derived class has access to private members of both base classes. In contrast, extension methods don't break encapusulation - you can't access private members.

There is another concept in object oriented design, which is the idea of an extension class - you can extend an existing class with additional storage and methods. (Think: add a object as an annotation to another object.) There are no mainstream languages that implement this idea. I've only seen proofs-of-concept prototype languages that do this. Extension methods are a partial implementation of 'extension classes'. When you have a general purpose mechanism such as annotations in LINQ to XML, then annotations+extension methods effectively equals extension classes, although the syntax isn't perfectly clean (but it's not bad). I've also seen the idea of extension properties batted around. But there are serious performance issues unless the properties are added as an annotation of some sort.

So, my point of view is: it isn't really an implementation of an 'is a' relationship. It is an approach to extending classes and interfaces, - a partial implementation of 'extension classes'.

Interestingly, I have never encountered a class design problem where I absolutely needed to use multiple implementation inheritance. So far, there have always been other ways to look at it, and other patterns to use that solve the designated problem without saying that one particular class has an 'is a' relationship to two parent classes. Multiple interface inheritance is another matter - important for a variety of reasons.

-Eric

Lambda Expressions

Eric White's Blog — Tue, 29 Jul 2008 08:24:03 GMT

[Table of Contents] [Next Topic] In order to learn functional programming and a more declarative style

re: Extension Methods

Kirk.B — Thu, 31 Jul 2008 16:12:26 GMT

You say "There are times that writing extension methods on IEnumerable<T> is the way that you want do things."

But I don't see where. Ther are so many already. I sure would like an example.

Could be one later in the series... I haven't been through the whole thing.

re: Extension Methods

EricWhite — Thu, 31 Jul 2008 17:11:36 GMT

@Kirk.B,

There are two situations where I've used extension methods to good effect:

1) Sometimes you want to add functionality to a sealed class. Here are two examples:

http://blogs.msdn.com/ericwhite/archive/2008/07/09/open-xml-sdk-and-linq-to-xml.aspx

http://blogs.msdn.com/ericwhite/archive/2006/08/31/734383.aspx

2) There is, for instance, grouping functionality that is difficult to get out of the standard extension methods:

http://blogs.msdn.com/ericwhite/archive/2008/04/21/the-groupadjacent-extension-method.aspx

Extension methods are one of the syntactical constructs that allow us to gain composability. Composability allows us to embed / add / remove / inject / surround / refactor code with a cleaner syntax, and avoid brittleness at the same time.

Does this make sense?

-Eric

re: Extension Methods

Kirk.B — Mon, 04 Aug 2008 18:07:12 GMT

Eric,

Thanks for the links. I especially appreciate the GroupAdjacent extension method.