Обоснование позади ASP.NET MVC ActionResult, являющегося абстрактным классом? [закрытый]
Проблема заключается в выражении return, которое завершит вызов функции и передаст результат туда, откуда он был вызван. Функция может когда-либо return значения только один раз за вызов. Если вы хотите, чтобы функция продолжалась, вы можете либо собрать свои переменные и вернуть их в конце, либо использовать ключевое слово yield, которое будет возвращать значение при каждом нажатии этой строки.
2 ответа
Интерфейсы являются большими для разрешения класса реализовать несколько контрактов, такой как тогда, когда Вы знаете, что тип должен быть двумя разными вещами. В некоторых случаях это может поощрить создавать тип, который имеет слишком много обязанностей.
Результаты действия несут единственную ответственность, и не казалось, что будет любой сценарий, где Вам нужен объект быть и результатом действия и чем-то еще. Даже если Вы сделали, возможно сделать через состав. Так в этом случае мы пошли с ABS, чтобы позволить нам большую гибкость после того, как мы RTM для внесения изменений при необходимости.
Однако, если бы существует определенный сценарий, мы блокируемся, в котором интерфейс был бы предпочтителен, мы рассмотрим это. Мы можем всегда сделать это позже способом, который это не повреждает.
Можно даже сделать это сами путем записи собственного действия invoker, который только требует, чтобы Вы реализовали IActionInvoker (интерфейс) и что invoker мог проверить на Ваш собственный IActionResult, а не ActionResult.
Я собираюсь предполагать, потому что они ожидали ActionResult для получения методов и свойств по жизни CTP/beta. Если бы это был интерфейс, то каждое изменение в IActionResult взломало бы существующий код. Добавление другого метода к абстрактному базовому классу не вызвало бы проблем.