Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, gandjustas, Вы писали:

G>>Для этого фильтры есть, зачем тебе наследование?

D>Кроме того, наследование (особенно template method, конкретно мною сделанный и полностью меня устраивающий) помогает структурировать мозги и код. А ещё по нему проще понять, что ожидается от реализации, чем от расположенных хрен знает где (и скорее всего даже не в одном месте, если среди них есть и библиотечные, и app-specific) третьих методов, пользы от которых для читаемости и обучения ничуть не больше, чем от жавовских аннотаций.

В asp.net mvc все построено на конвенциях. По умолчанию, если ты вызываешь /home/index, то ищется HomeController, в нем ищется метод Index. который должен вернуть IActionResult. Все, остальное не забота фреймворка и разруливается программистом. Причем ASP.NET MVC сам подсказывает что нужно сделать. Он честно скажет что не найден метод в таком-то классе и такой-то сигнатурой.

Кстати IActionResult имеет один метод Execute и вообще не было бы смысла плодить интерфейс, если бы делегаты работали быстрее и можно было делать алиасы для типов.

D>UPD. Т.е. слабая связность имеет и свои обратные стороны (которые, кстати, тут неоднократно упоминались в контексте DI-фреймворков): когда код вообще ни хрена не связан, концы вообще хрен найдёшь.
Ну это банальная история. Пишется код, который разбивается на набор классов, вызывающих друг друга. Потом для покрытия тестами создаются везде интерфейсы и ссылки на классы заменяются на ссылки на интерфейсы, а экземпляры подсовываются через IOC. Дальше оказывается, что внесение изменений требует правки интерфейса, класса и пересборки всех ссылающихся на интерфейс. Тогда приходит в голову гениальная идея, вместо прямого вызова сделть "общую шину", через которую вызывать другие классы и все, концов уже не найдешь.


А всего-то надо было не заморачиваться с тестами.