I've been thinking about using extension methods as a replacement for an abstract base class. The extension methods can provide default functionality, and can be 'overridden' by putting a method of the same signature in a derived class.
Any reason I shouldn't do this?
Also, if I have two extension methods with the same signature, which one is used? Is there a way of establishing priority?
In general, you shouldn't provide "base" functionality through extension methods. They should only be used to "extend" class functionality. If you have access to the base class code, and the functionality you're trying to implement is logically part of the inheritance heirarchy, then you should put it in the abstract class.
My point is, just because you can doesn't mean you should. It's often best just to stick with good old fashioned OOP and use the newer language features when plain old OO programming falls short of providing you a reasonable solution.
This is definitely a bad idea. Extension methods are bound statically which means that, unless your calling the override on an object whose compile-time type is the sub-type, you'll still continue to call the extension method. Bye-bye polymorphism. This page has a good discussion of the perils of extension methods.
All answers here stated "you can't", which is true as far as it goes. Most added "and you shouldn't". I would like to make the case that you should be able to - small comfort as this may be.
Take a painful real world example: if you are unfortunate enough to be using the new MVC framework, and your view code is using some HtmlHelper extension method all over the place, and you want to override its default behavior... what then?
You are SOL, that's what. Even if you did the "OOP thing" - derive from HtmlHelper, change your base view class to replace the 'Html' object instance with an instance of your DerivedHtmlHelper, and define an explicit 'Foo' method in it - even if you did all that, calling 'Html.Foo' will still invoke the original extension method and not method.
This is surprising! After all, extension methods are only expected to be applied if the object does not already have a method! What's going on here?
Well, this because extension methods are a static feature. That is, when seeing 'Html.Foo', the compiler looks at the static type of 'Html'. If it has a 'Foo' method, it is called as usual. Otherwise, if there is 'SomeClass' providing a 'Foo' extension method, it converts the expression to 'SomeClass.Foo(Html)'.
What you would expect is that the compiler would consider the dynamic type of the object. That is, that the generated (pseudo-)code would read 'Html.HasMethod("Foo") ? Html.Foo() : SomeClass.Foo(Html)'.
This of course would incur the cost of using reflection in each extension method call. So, you would expect that you could write something like 'static void Foo(virtual this HtmlHelper html)' to explicitly request the compiler to insert the run-time check. Call this a "virtual extension method".
However, in their limited budget and infinite wisdom, the C# language designers went with only the more efficient, more restricted alternative. Which leaves me still SOL when I need to override the default behavior of HtmlHelper :-(
I agree with Michael. Base classes should contain all base functionality Extension methods should, obviously, extend the base functionality. In dynamic languages like Ruby it is often typical to use extension methods to provide addition functionality instead of using subclasses. Basically, extension methods are there to replacing using subclassses, not to replace using base classes.
The only exception to this that I've seen is if you have multiple type that have different class hierachies (like winform controls), you can make a subclass of each that all implement and interface and then extend that interface, thereby giving "base" functionality to a group of different controls, without extending everything like Control or Object.
Edit: answering your second question
I think the compiler will catch this for you.
You may want to consider foregoing polymorphism if you don't need unique derivative classes.
A few general guidelines from this MSDN article:
Once a method is defined within a class, any extension method for that class sharing that method name will no longer be executed.
Extension methods are loaded by namespace. To allow the user of other extension methods, you should probably avoid putting the extension methods in the same namespace as the class being extended.
If various dependent assemblies are consuming the same library, each requiring a customized function against a class in the library, you could declare the extension specific to the dependent assembly in a namespace within that assembly. Other assemblies which don't depend on that assembly won't have that extension.
While this is not polymorphism, you may not want to use polymorphism as it would require all derived classes to implement their overrides.
In other words, if you have derivatives with specific, variant logic, use polymorphism. If you are simply needing custom functions in specific cases that otherwise might be confusing or burdensome, extension methods are not a bad idea.
Also, see JoshRivers' answer showing how to override an extension method using a namespace within a class within a separate namespace.
They're semantically different operations. For example, polymorphism may not work the way it would with an abstract base class.
As a general rule, use any language tool for what it's designed for. Extension methods aren't a replacement for inheritance, they're a technique to extend the functionality of a class using (typically) it's already-visible interface.
There's every reason you shouldn't do it. The first of which is, you can't guarantee how your extensions will be called:
MyExtensions.AMethod(myObj)
or
myObj.AMethod()
The second is merely syntactic sugar for the first.
What you suggest goes against the spirit of the language feature. Extension methods are decidedly not object-oriented. Yet you are trying to achieve an object-oriented technique. Don't use extension methods for that.
Adding a link to another SO question that has an alternate answer than the "You can't". More 'you can't....unless'.
First it would be good to check [new] as a method modifier - it should give the same perf and method separation but with a lot less of a hassle.
If after that you are are still pondering the same tricks, here are the principal options to consider - no ideology involved, just listing apsects you'll need to be aware of :-)
For a start you may have to limit all uses to templated function params in order to guarantee deterministic function selection since this trick will create the situation which is exact inverse of the one in which CLR guarantees deterministic binding priority across function call boundaries.
If you are still going to have abstract base class and you own all code then just "converting" one base method into extension weill not buy you anything at all and will just cost you the loss of a common interface which will still exist for everything else, including the cost of vtables.
If you are aiming at converting abstract class into a concrete, eliminating all virtual methods for perf reasons and using using concrete base class and all derivatives exclusively in templates (maybe even converting to structs) then that trick could buy you some perf. You just need to be aware that you won't be able to go back to interface-based use without refactoring. You'll also need to test invocation order in non-template functions with the base class in signature and be extra carefull if you have multiple dlls-s. Try the same with [new] operator and see if it works better.
Also, you will have to write separate method implementation for each derived class even if they have exactly the same functionality, so if you have a lot of derived classes you are looking at a lot of code duplication. This part will hit you even if you use [new] unless you go back to virtual methods and introduce another layer in inheritance - which will cancel all perf gains of course.
