Why the required Startup class does't need to implement an appropriate interface, like IStartup?

Question

Using katana, why does the Startup class should not implement a respective interface, like for example:

interface IStartup
{
  void Configuration(IAppBuilder app);
}

public class MyStartup : IStartup
{
    public void Configuration(IAppBuilder app)
    {
       ...
    }
}

I think that it could be much more intuitive for the developers to understand what they should provide with to the WebApp.Start<T> method as the T argument instead of guessing and looking for examples, it should be more explicit:

public void Start<T>() where T : IStartup

Is there ever more than one Startup class? Isn't the method that you're implementing the same anyway? — Robert Harvey, Oct 14 '14 at 19:30
@RobertHarvey yes, could be more than 1 Startup class, for example, when I'm unit-testing and need some mock server. — Yair Nevet, Oct 14 '14 at 19:44
@RobertHarvey If you run into the following code `WebApp.Start`, how could you figure out what the required `T` should be without looking at docs and examples? — Yair Nevet, Oct 14 '14 at 19:52
I'm having trouble figuring out how that is different from simply having the same constraints on the actual implementation method. — Robert Harvey, Oct 14 '14 at 19:56
Now I'm having trouble figuring out what you meant, an answer with example will be perfect. — Yair Nevet, Oct 14 '14 at 20:07
What prevents you from doing exactly the same thing you propose, but without using an interface? **Assumption:** interfaces are often overused: prove that you need it. — Robert Harvey, Oct 14 '14 at 20:08
It turns out that I'm not a lone ranger at this field: http://stackoverflow.com/q/24935092/952310 — Yair Nevet, Oct 14 '14 at 20:16
Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/63060/discussion-between-robert-harvey-and-yair-nevet). — Robert Harvey, Oct 14 '14 at 20:17

score 5 · Accepted Answer · answered Mar 17 '15 at 17:51

5

The reason is "there's NO GOOD reason". Interfaces exist to communicate structure and purpose to an implementer (abstract classes do this as well, along with providing some minimal behavior). Without them, we're left with convention. In this case, by not constraining TStartup, OWIN is allowing you to use any nonsense Startup class and can only tell you at runtime if it will work. For example:

WebApp.Start<string>(BaseAddress);

This compiles fine but throws an EntryPointNotFoundException at runtime (No 'Configuration' method was found in class 'System.String).

Not to get all philosophical, but I see this as a general trend in computing today. REST, with it's no contracts, no guarantees, you figure it out paradigm is in; SOAP is out. In some ways this is a good thing, but I don't think this example is one of them.

answered Mar 17 '15 at 17:51

Scott Hilleque

66
1
2

Thanks for answer and sorry for the late response. – Yair Nevet Jul 09 '15 at 06:29
This does allow OWIN to be extended in the future without breaking existing code. The only way to do that with interfaces is to version them which also has pros and cons. – bikeman868 Sep 21 '16 at 21:58
This looks like golang interfaces philosophy: no class implements any interface explicitly, but rather if a class corresponds to some interface, then the class automatically implements it – manda Oct 22 '18 at 11:01

Why the required Startup class does't need to implement an appropriate interface, like IStartup?

1 Answers1

Linked