Last week I showed some ways to utilize extension methods. In this post I’ll go on with a more advanced example and also discuss some of the limitations.

Method-Only Multiple Inheritance

A combination of interfaces and extension methods can be used to partly work around the single inheritance limitation of C#. Assume that I have a class hierarchy of animals. Some of the animals are possible to ride, but they are spread across the hierarchy and cannot share a common base class. In C# we can use an interface to get a type safe way to indicate that an animal is possible to ride.



public interface IRideable { void Mount ( ) ; void Start ( ) ; } public abstract class Animal { public string Name { get ; set ; } } public abstract class HorseAnimal : Animal { } public class Zebra : HorseAnimal { } public class Horse : HorseAnimal, IRideable { virtual void Mount ( ) { Debug . WriteLine ( "Swing into the saddle" ) ; } virtual void Start ( ) { Debug . WriteLine ( "Press heels into horse's side" ) ; } } public class Elephant : Animal, IRideable { void Mount ( ) { Debug . WriteLine ( "Climb the ladder" ) ; } void Start ( ) { Debug . WriteLine ( "Poke behind ears with toes" ) ; } } public interface IRideable { void Mount(); void Start(); } public abstract class Animal { public string Name { get; set; } } public abstract class HorseAnimal : Animal { } public class Zebra : HorseAnimal { } public class Horse : HorseAnimal, IRideable { virtual void Mount() { Debug.WriteLine("Swing into the saddle"); } virtual void Start() { Debug.WriteLine("Press heels into horse's side"); } } public class Elephant : Animal, IRideable { void Mount() { Debug.WriteLine("Climb the ladder"); } void Start() { Debug.WriteLine("Poke behind ears with toes"); } }

If this would have been C++ where multiple inheritance is allowed it would be possible to add a method Ride() to the IRideable interface that combines the mount and start operations needed to take a ride. One way is to add the Ride() method to the Animal with a default implementation that throws an exception, but I don’t like that. I prefer to catch the errors at compile time and not runtime.

A better way in C# is to create an extension method.

public static class RideableExtensions { public static void Ride ( this IRideable animal ) { animal . Mount ( ) ; animal . Start ( ) ; } } public static class RideableExtensions { public static void Ride(this IRideable animal) { animal.Mount(); animal.Start(); } }

That will allow us to call a Ride() method on any animal implementing IRideable .

Limitations

As good as extension methods are, they are still subject to some limitations. Both of them are related to the fact that they are just a syntactic construct which is expanded during compilation.

No polymorphism

Extension methods have no support for polymorphism. To show the problem, I’ll extend the animal hierarchy with a wild horse and a corresponding Ride method in an extension class.

public class WildHorse : Horse { public void Catch ( ) { Debug . WriteLine ( "Catch the horse with lasso" ) ; } public override void Mount ( ) { Debug . WriteLine ( "Swing onto back" ) ; } public override void Start ( ) { Debug . WriteLine ( "ERROR: Horse already running" ) ; } } public static class WildHorseExtensions { public static void Ride ( this WildHorse horse ) { horse . Catch ( ) ; horse . Mount ( ) ; // No need to start, the wild horse is already // running for it's life when someoune mounts. } } public class WildHorse : Horse { public void Catch() { Debug.WriteLine("Catch the horse with lasso"); } public override void Mount() { Debug.WriteLine("Swing onto back"); } public override void Start() { Debug.WriteLine("ERROR: Horse already running"); } } public static class WildHorseExtensions { public static void Ride(this WildHorse horse) { horse.Catch(); horse.Mount(); // No need to start, the wild horse is already // running for it's life when someoune mounts. } }

I’ve created some sample code to test the new WildHorse class.

Debug . WriteLine ( "Riding horse..." ) ; Horse horse = new Horse ( ) ; horse . Ride ( ) ; Debug . WriteLine ( "Riding wild horse..." ) ; WildHorse wildHorse = new WildHorse ( ) ; wildHorse . Ride ( ) ; Debug . WriteLine ( "Treating wild horse as horse..." ) ; horse = wildHorse ; horse . Ride ( ) ; Debug.WriteLine("Riding horse..."); Horse horse = new Horse(); horse.Ride(); Debug.WriteLine("Riding wild horse..."); WildHorse wildHorse = new WildHorse(); wildHorse.Ride(); Debug.WriteLine("Treating wild horse as horse..."); horse = wildHorse; horse.Ride();

The output shows the problem.

Riding horse... Swing into the saddle Press heels into horse's side Riding wild horse... Catch the horse with lasso Swing onto back Treating wild horse as horse... Swing onto back ERROR: Horse already running Riding horse... Swing into the saddle Press heels into horse's side Riding wild horse... Catch the horse with lasso Swing onto back Treating wild horse as horse... Swing onto back ERROR: Horse already running

It is clear that the compile time type is used when choosing what extension method to use. If the wild horse is assigned to a Horse reference, the special overload for the wild horse won’t be called. Instead the ordinary IRideable extension is called.

No dynamic support

Another problem on the same theme is the lack of dynamic support for extension methods. Changing the type of the variable from the last example to dynamic compiles, but gives a runtime error.

dynamic horse = new Horse ( ) ; // Throws a RuntimeBinderException horse . Ride ( ) ; dynamic horse = new Horse(); // Throws a RuntimeBinderException horse.Ride();

The reason is that for non dynamic types, the horse.Ride() syntax is expanded during compilation to RideableExtensions.Ride(horse) . To find the correct Ride() method, the compiler searches all static classes in all namespaces included by using blocks. That information is only available in the source file so the runtime binder has no way to know where to search. Eric Lippert explains that the C# team considered adding support for this, but decided it wasn’t worth it.

To summarize I think that extension methods are an excellent syntactic sugar that enables constructs to be used that would otherwise be totally unreadable. I’ve found that I often write helper methods as extension methods to benefit from the easier syntax (and intellisense!) on the call site.

Posted in C# on 2012-05-21 | Tagged Extension Methods