Reasoning behind ASP.NET MVC ActionResult being an abstract class?

In ASP.NET MVC, the ActionResult class, which is the base for all results returned by action methods from a controller, is defined as an abstract class with the single method (© Microsoft):

public abstract void ExecuteResult(ControllerContext context);

Can you think of any specific reasons for this design? Specifically, it seems a bit weird to me, that

• there is no IActionResult interface,
• and that the class would not be required at all, if there was such an interface.

After all, if this was an interface instead of that abstract class, there would be no need to extend a base class in order to create a new ActionResult - one would just have to implement IActionResult properly. In a world, err language, without multiple inheritance, this advantage would seem quite important to me.

From stackoverflow

• I'm gonna guess because they were anticipating the ActionResult to gain methods and properties over the life of the CTP/beta. If it was an interface, every change to IActionResult would break existing code. Adding another method to the abstract base class wouldn't cause any problems.

  Shahin : back of the net!

  hangy : Breaking changes were done during the CTP phase anyway, so that would probably be a lame reason. :) Anyway, your guess could be close to what they thought. I hope they decide on some interface instead of the abstract class before a release, though.

• Interfaces are great for allowing a class to implement multiple contracts, such as when you know that a type must be two different things. In some cases, this can encourage creating a type that has too many responsibilities.

  Action results have a single responsibility and it didn't seem like there would be any scenario where you need an object to be both an action result and something else. Even if you did, it's possible to do via composition. So in this case, we went with ABS to allow us greater flexibility after we RTM to make changes if necessary.

  However, if there's a specific scenario we're blocking in which an interface would be preferable, we'll consider it. We can always do it later in a manner that's not breaking.

  You can even do it yourself by writing your own action invoker, which only requires you to implement IActionInvoker (an interface) and that invoker could check for your own IActionResult rather than ActionResult.

  joshperry : I ran into an issue today that this blocks me on. I want to implement an ActionResult as an ExpandoObject so that I can have the controller add members to the ActionResult dynamically. But my class can't be an ActionResult _and_ an ExpandoObject without MI...

  Haacked : What you can do is have an ActionResult class that also implements IDynamicMetaObjectProvider (see http://msdn.microsoft.com/en-us/library/system.dynamic.idynamicmetaobjectprovider.aspx). In the implementation of that interface, you delegate to an internal Expando object.

  Nissan Fan : Love when Phil Haack comes in from the ASP.NET MVC team and gives the definitive answer. Kudos to their involvement in the community.