What is the point of this code?

Question

I'm reading through the source code for ASP.NET MVC3, and I came across the following inside of the code for ControllerBase:

public interface IController
{
    void Excecute(RequestContext requestContext);
}


public abstract class ControllerBase : IController
{

    protected virtual void Execute(RequestContext requestContext)
    {
        if (requestContext == null)
        {
            throw new ArgumentNullException("requestContext");
        }
        if (requestContext.HttpContext == null)
        {
            throw new ArgumentException(MvcResources.ControllerBase_CannotExecuteWithNullHttpContext, "requestContext");
        }

        VerifyExecuteCalledOnce();
        Initialize(requestContext);

        using (ScopeStorage.CreateTransientScope())
        {
            ExecuteCore();
        }
    }

    void IController.Execute(RequestContext requestContext)
    {
        Execute(requestContext);
    }
}

ControllerBase provides an implementation of Execute, but then it has something that provides a definition for.. IController.Execute?

Why is this done, and what does it achieve? It seems like it serves no purpose.

If you overrode the virtual `Execute`, would the explicit `IController.Execute` still execute the base implementation? — Joe, Apr 12 '12 at 21:39
@Joe No. It would execute an overriden virtual Execute, if one exists. — Scott, Apr 12 '12 at 21:42
So maybe it's just a hack to get that method `protected` and not `public` then. — Joe, Apr 12 '12 at 21:44
@Joe Could be. That's what vhallac suggested, to enforce separation of responsibilities. — Scott, Apr 12 '12 at 22:04

score 6 · Accepted Answer · answered Apr 12 '12 at 21:57

6

This code makes it possible for you to override the Execute method.

Remember that a normally implemented interface method is public (and not virtual or abstract), so you can't override it in derived classes and creating a new Execute method wouldn't be accessible through the IController interface by default (without this interface to protected virtual technique). By creating a protected virtual method (which you call from the explicitly implemented interface method) allows derived classes to override the Execute method without breaking the interface implementation.

I found an excellent article about this here: C# Overriding Interface Methods in Subclasses

answered Apr 12 '12 at 21:57

BenSwayne

16,810
3
58
75

So essentially if I want to expose some functionality via interface that I want to be changed out in a subclass, I can use this pattern. – Mike Bailey Apr 12 '12 at 21:58
Why would you favor this design pattern over `public virtual Execute(RequestContext requestContext)`? – Scott Apr 12 '12 at 22:03
2

@Scott using public virtual would allow it to be accessed from outside this class without a reference to the IController interface. It'd be public. Using protected keeps your method internal to ControllerBase class and its descendants unless you have an explicit reference to the IController interface. So its better protected and only used when very intentionally accessed. – BenSwayne Apr 12 '12 at 22:06

score 2 · Answer 2 · answered Apr 12 '12 at 21:51

According to MSDN Documentation, one purpose of explicit interface member implementation is: "Because explicit interface member implementations are not accessible through class or struct instances, they allow interface implementations to be excluded from the public interface of a class or struct. This is particularly useful when a class or struct implements an internal interface that is of no interest to a consumer of that class or struct."

If my interpretation of the above is correct, a variable with type ControllerBase cannot be used to call Execute because it is protected. The type of the variable has to be IController. I am not sure if this is the intent of the construct, but it feels like this is the reason.

In the relevant tests, they explicitly cast the ControllerBase variables to IController before calling Execute.

Yup. Perhaps it is just a fancy way to obscure the Execute call from the "outside". — Scott, Apr 12 '12 at 21:56
@Scott My guess is that this is used to enforce separation of responsibilities. If you hold a `ControllerBase` reference, you are not meant to execute it. If you hold an `IController`, you are meant to execute it only. — vhallac, Apr 12 '12 at 21:57

score 1 · Answer 3 · answered Apr 12 '12 at 21:53

At first glance this design pattern would seem to serve no purpose. It does, however, provide the opportunity for the ControllerBase class to later make non-breaking changes its implementation of the IController interface. The changes would be guaranteed to run, as it does not rely on the inherited classes calling base.Execute(). Perhaps this could be used to manage contexts or security in the future?

Maybe the developer just likes to keep a logical separation of the interface with overridable implementation.

What is the point of this code?

3 Answers3