Overriding Extension Methods

Question

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 \'overridd

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

You may want to consider foregoing polymorphism if you don't need unique derivative classes.

A few general guidelines from this MSDN article:

1. Once a method is defined within a class, any extension method for that class sharing that method name will no longer be executed.

2. 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.

Answer 6

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.