Зло.

Тут, скорее, между добром и злом :))

Я еще могу понять (с огромнейшим натягом) наследование ради наследования какого-нибудь нетривиального функционала, но наследование ради наследования одного поля это откровенное зло. Да и вообще наследование постоянно абьюзят так, что его вообще запретить впору. Можно было бы, например, в csc добавить какую-нибудь опцию типа "sealed by default"

Рихтер, Саттер и АА - компашка хейтеров

Ну так и я ведь не писал, что наследование это Зло. Сказал только что его абьюзят. Бухлом тоже некоторые пассажиры абьюзят, но это не значит что совсем никогда нельзя побухать

А это что за зверь такой?

Корень зла тут в наследовании Не в самом наследовании, а в его использовании как корявой замены композиции, потому что кажется, что "так проще". А потом всё это начнет разрастаться и выяснится, что в некоторых контроллерах это поле вообще не нужно, а в некоторых оно вроде как и нужно, но немного другое. И вот тут начнутся фейверки.

Хм... А что там необычного, и при чем там делегаты? Всему что там написано уже сто лет в обед.

Но в данном случае грядет говнокод почему-то именно с наследованием


При чем тут это - там DI встроенного вообще не было. Я просто так и не понял, при чем там по твоей ссылке именно делегаты и их инжекция. Сначала даже подумал, что в дотнет delegate factories завезли, как в автофаке, но зашел и не увидел ничего нового.

Ну и при чем здесь все-таки какие-то делегаты? И это не совсем иньекция - это скорее сервис-локатор, который запрятан в фреймворке и вызывается при вызове Invoke. Такая же тема есть для акций контроллеров, но с совершенно произвольным методом такой фокус не пройдет, да и невозможен хотя бы из-за синтаксиса C#.


Время просыпаться . Новым это было в 2.1.


В МВЦ5 вообще мидлеваров не было. Был со стороны OWIN, который, кстати, с автофаком интегрировался . В Invoke он инжектить не мог, но там и нужды такой не было, т.к. инстанс мидлевара создавался per request.

В смысле, что это специфичная иньекция, работающая только в конкретном случае, а не где угодно, как иньекция в конструктор.


DI может быть вообще без какого-либо контейнера или фреймворка. DI говорит только о разделении создания зависимости и её использования.


В коре мидлеваре это синглетон. Если бы не было этой фичи, то это пришлось бы делать обходными путями (например, с помощью фабрики).

Нет, не путаю. Сам по себе принцип DI - разделение использования зависимости и создания её экземпляра ничего не говорит о том как эта зависимость должна создаваться. И ты сам же выше об этом написал:


Все уже и так давно знают, что на всем форуме читать умеешь только ты. Как поп в сельской церкви. Так что можешь уже не утруждаться и не упоминать об этом в каждом сообщении.

Скорее частный случай применения. Потому что IoC очень сильно намного шире, чем DI. Например, когда ты в очередной раз пишешь свой любимый button_Сlick, то ты, на самом деле, тоже используешь IoC. Если посмотреть на SOLID, то IoC это "O", а DI где-то ближе к "D".

А ты скажи своей мобиле "Hey Google!" и спроси у неё, что означает аббревиатура IoC.

wikiИнверсия управления (англ. Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, используемый для уменьшения зацепления (связанности) в компьютерных программах. Также архитектурное решение интеграции, упрощающее расширение возможностей системы, при котором поток управления программы контролируется фреймворком.

В обычной программе программист сам решает, в какой последовательности делать вызовы процедур. Но, если используется фреймворк, программист может разместить свой код в определенных точках выполнения (используя callback или другие механизмы), затем запустить «главную функцию» фреймворка, которая обеспечит все выполнение и вызовет код программиста тогда, когда это будет необходимо. Как следствие, происходит утеря контроля над выполнением кода — это и называется инверсией управления (фреймворк управляет кодом программиста, а не программист управляет фреймворком).



Очень даже имеет, пускай даже и не прямое (я и не говорил что это прямо-таки одно и то же). Потому что при IoC мы расширяем/модифицируем поведение приложения не меняя ничего в существующем фреймворке (закрытость к изменениям), а дополняя его своими "расширениями" в виде коллбеков, обработчиков событий и, в том числе, инжекцией зависимостей, которые этот фрейморк будет вызывать (открытость к расширению).


Ты разве забыл, что я читать не умею - в нашем кишлаке школы не было

Я же процитировал ниже.


Наводящий вопрос - а уменьшение связности это самоцель или все-таки тоже для чего-то служит?

См. выше. Изменение направления контроля тоже только ради изменения направления контроля?

Ты как те слепые из притчи, которые трогали слона за хер различные части тела. Где-то на что-то наткнулся, прочитал, запомнил, а общей картины у тебя так и нет. Потому что надо не только читать и запоминать, а еще и хоть немного пытаться это осмысливать.

wiki Inversion of control is used to increase modularity of the program and make it extensible , and has applications in object-oriented programming and other programming paradigms. The term was used by Michael Mattsson in a thesis, taken from there by Stefano Mazzocchi and popularized by him in 1999 in a defunct Apache Software Foundation project, Avalon, then further popularized in 2004 by Robert C. Martin and Martin Fowler.

The term is related to, but different from, the dependency inversion principle, which concerns itself with decoupling dependencies between high-level and low-level layers through shared abstractions. The general concept is also related to event-driven programming in that it is often implemented using IoC so that the custom code is commonly only concerned with the handling of events , whereas the event loop and dispatch of events/messages is handled by the framework or the runtime environment.

Я хз, потому что читаю практически только англоязычные источники. Loose coupling.


При чем тут контейнер вообще. Там даже ниже по процитированной ссылке:
wikiInversion of control carries the strong connotation that the reusable code and the problem-specific code are developed independently even though they operate together in an application. Callbacks, schedulers, event loops, dependency injection, and the template method are examples of design patterns that follow the inversion of control principle , although the term is most commonly used in the context of object-oriented programming.
Контейнер это как раз хер хобот слона, за который ты сейчас держишься


Чушь. Где я такое говорил. Событийная модель - один из авторexamples of design patterns that follow the inversion of control principle