Почему требуемый класс Startup не нуждается в реализации соответствующего интерфейса, такого как IStartup?

Используя катану, почему класс Startup не должен реализовывать соответствующий интерфейс, например:

interface IStartup
{
  void Configuration(IAppBuilder app);
}

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

Я думаю, что разработчикам было бы гораздо более интуитивно понятно, что они должны предоставить методу WebApp.Start<T> в качестве аргумента T, вместо того, чтобы гадать и искать примеры, это должно быть более явным:

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

c# owin katana
person Yair Nevet    schedule 14.10.2014    source источник
comment
Существует ли когда-либо более одного класса Startup? Разве метод, который вы реализуете, не один и тот же?   -  person Robert Harvey    schedule 14.10.2014
comment
@RobertHarvey да, может быть более 1 класса Startup, например, когда я провожу модульное тестирование и мне нужен фиктивный сервер.   -  person Yair Nevet    schedule 14.10.2014
comment
@RobertHarvey Если вы столкнетесь со следующим кодом WebApp.Start<T>, как вы сможете понять, каким должен быть требуемый T, не глядя на документы и примеры?   -  person Yair Nevet    schedule 14.10.2014
comment
Как интерфейс скажет вам, что такое T?   -  person Robert Harvey    schedule 14.10.2014
comment
Вы можете использовать ограничения аргумента T (where).   -  person Yair Nevet    schedule 14.10.2014
comment
У меня возникли проблемы с выяснением того, чем это отличается от простого наличия тех же ограничений в фактическом методе реализации.   -  person Robert Harvey    schedule 14.10.2014
comment
Теперь мне трудно понять, что вы имели в виду, ответ с примером будет идеальным.   -  person Yair Nevet    schedule 15.10.2014
comment
Что мешает вам сделать ровно то же самое, что вы предлагаете, но без использования интерфейса? Предположение: интерфейсами часто злоупотребляют: докажите, что они вам нужны.   -  person Robert Harvey    schedule 15.10.2014
comment
Оказывается, я не одинокий рейнджер в этом поле: stackoverflow.com/q/24935092/952310   -  person Yair Nevet    schedule 15.10.2014
comment
Давайте продолжим обсуждение в чате.   -  person Robert Harvey    schedule 15.10.2014

Ответы (1)


arrow_upward
5
arrow_downward

Причина в том, что "НЕТ ВЕЛИКОЙ причины". Интерфейсы существуют для сообщения структуры и назначения разработчику (абстрактные классы также делают это, наряду с обеспечением некоторого минимального поведения). Без них мы остаемся с условностями. В этом случае, не ограничивая TStartup, OWIN позволяет вам использовать любой бессмысленный класс Startup и может только сказать вам во время выполнения, будет ли он работать. Например:

WebApp.Start<string>(BaseAddress);

Это компилируется нормально, но генерирует EntryPointNotFoundException во время выполнения (метод «Конфигурация» не был найден в классе «System.String»).

Не вдаваясь в философию, я считаю это общей тенденцией в компьютерных технологиях сегодня. ОТДЫХ, без контрактов, без гарантий, вы понимаете, что это парадигма; Мыло закончилось. В некотором смысле это хорошо, но я не думаю, что этот пример является одним из них.

person Scott Hilleque    schedule 17.03.2015
comment
Спасибо за ответ и извините за поздний ответ. - person Yair Nevet; 09.07.2015
comment
Это позволяет расширять OWIN в будущем, не нарушая существующий код. Единственный способ сделать это с интерфейсами — версионировать их, что также имеет свои плюсы и минусы. - person bikeman868; 22.09.2016
comment
Это похоже на философию интерфейсов golang: ни один класс не реализует какой-либо интерфейс явно, но если класс соответствует какому-то интерфейсу, то класс автоматически реализует его. - person manda; 22.10.2018