{"id":3508,"date":"2012-03-08T15:19:00","date_gmt":"2012-03-08T15:19:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/why-you-shouldnt-add-methods-to-interfaces-in-apis\/"},"modified":"2016-07-28T10:50:44","modified_gmt":"2016-07-28T10:50:44","slug":"why-you-shouldnt-add-methods-to-interfaces-in-apis","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/why-you-shouldnt-add-methods-to-interfaces-in-apis\/","title":{"rendered":"Why you shouldn’t add methods to interfaces in APIs"},"content":{"rendered":"

It is an oft-repeated maxim that you shouldn’t add methods to a publically-released interface in an API. Recently, I was hit hard when this wasn’t followed.<\/p>\n

As part of the work on ApplicationMetrics<\/a>, I’ve been implementing auto-reporting of MVC action methods; whenever an action was called on a controller, ApplicationMetrics would automatically report it without the developer needing to add manual ReportEvent<\/code> calls. Fortunately, MVC provides easy hook when a controller is created, letting me log when it happens – the IControllerFactory<\/code> interface.<\/p>\n

Now, the dll we provide to instrument an MVC webapp has to be compiled against .NET 3.5 and MVC 1, as the lowest common denominator. This MVC 1 dll will still work when used in an MVC 2, 3 or 4 webapp because all MVC 2+ webapps have a binding redirect<\/a> redirecting all references to previous versions of System.Web.Mvc to the correct version, and type forwards<\/a> taking care of any moved types in the new assemblies. Or at least, it should.<\/p>\n

IControllerFactory<\/h4>\n

In MVC 1 and 2, IControllerFactory<\/code><\/a> was defined as follows: <\/p>\n

public interface IControllerFactory\n{\n    IController CreateController(RequestContext requestContext, string controllerName);\n    \n    void ReleaseController(IController controller);\n}<\/pre>\n
  So, to implement the logging controller factory, we simply wrap the existing controller factory:  <\/p>\n
internal sealed class LoggingControllerFactory : IControllerFactory\n{\n    private readonly IControllerFactory m_CurrentController;\n    \n    public LoggingControllerFactory(IControllerFactory currentController)\n    {\n        m_CurrentController = currentController;\n    }\n    \n    public IController CreateController(\n        RequestContext requestContext, string controllerName)\n    {\n        \/\/ log the controller being used\n        FeatureSessionData.ReportEvent(\"Controller used:\", controllerName);\n        \n        return m_CurrentController.CreateController(requestContext, controllerName);\n    }\n    \n    public void ReleaseController(IController controller)\n    {\n        m_CurrentController.ReleaseController(controller);\n    }\n}<\/pre>\n
Easy. This works as expected in MVC 1 and 2. However, in MVC 3 this type was throwing a TypeLoadException<\/code>, saying a method wasn’t implemented. It turns out that, in MVC 3, the definition of IControllerFactory<\/code> was changed to this<\/a>:<\/p>\n
public interface IControllerFactory\n{\n    IController CreateController(RequestContext requestContext, string controllerName);\n    \n    SessionStateBehavior GetControllerSessionBehavior(\n        RequestContext requestContext, string controllerName);\n        \n    void ReleaseController(IController controller);\n}<\/pre>\n
There’s a new method in the interface. So when our MVC 1 dll was redirected to reference System.Web.Mvc v3, LoggingControllerFactory<\/code> tried to implement version 3 of IControllerFactory<\/code>, was missing the GetControllerSessionBehaviour<\/code> method, and so couldn’t be loaded by the CLR.<\/p>\n
Implementing the new method<\/h4>\n
Fortunately, there was a workaround. Because interface methods are normally implemented implicitly in the CLR, if we simply declare a virtual method matching the signature of the new method in MVC 3, then it will be ignored in MVC 1 and 2 and implement the extra method in MVC 3:  <\/p>\n
internal sealed class LoggingControllerFactory : IControllerFactory\n{\n    ...\n    \n    public virtual SessionStateBehaviour GetControllerSessionBehaviour(\n        RequestContext requestContext, string controllerName) {}\n    \n    ...\n}<\/pre>\n
However, this also has problems – the SessionStateBehaviour<\/code><\/a> type only exists in .NET 4, and we’re limited to .NET 3.5 by support for MVC 1 and 2.<\/p>\n
This means that the only<\/em> solutions to support all MVC versions are:<\/p>\n
    \n
  1. Construct the LoggingControllerFactory<\/code> type at runtime using reflection<\/li>\n
  2. Produce entirely separate dlls for MVC 1&2 and MVC 3.<\/li>\n<\/ol>\n
    Ugh. And all because of that blasted extra method!<\/p>\n
    Another solution?<\/h4>\n
    Fortunately, in this case, there is a third option – System.Web.Mvc also provides a DefaultControllerFactory<\/code><\/a> type that can provide the implementation of GetControllerSessionBehaviour<\/code> for us in MVC 3, while still allowing us to override CreateController<\/code> and ReleaseController<\/code>.<\/p>\n
    However, this does mean that LoggingControllerFactory<\/code> won’t be able to wrap any calls to GetControllerSessionBehaviour<\/code>. This is an acceptable bug, given the other options, as very few developers will be overriding GetControllerSessionBehaviour<\/code> in their own custom controller factory.<\/p>\n
    So, if you’re providing an interface as part of an API, then please please please<\/em> don’t add methods to it. Especially if you don’t provide a ‘default’ implementing type. Any code compiled against the previous version that can’t be updated will have some very tough decisions to make to support both versions.<\/p>\n","protected":false},"excerpt":{"rendered":"
    It is an oft-repeated maxim that you shouldn’t add methods to a publically-released interface in an API. Recently, I was hit hard when this wasn’t followed. As part of the work on ApplicationMetrics, I’ve been implementing auto-reporting of MVC action methods; whenever an action was called on a controller, ApplicationMetrics would automatically report it without……<\/p>\n","protected":false},"author":186659,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"coauthors":[],"class_list":["post-3508","post","type-post","status-publish","format-standard","hentry","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/186659"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=3508"}],"version-history":[{"count":1,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3508\/revisions"}],"predecessor-version":[{"id":25470,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3508\/revisions\/25470"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=3508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=3508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=3508"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=3508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}