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

Question

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.

Answer 1

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.