История изменений

Инверсия управления должна быть для уменьшения связности. Сама по себе низкая связность неплохо (хотя и имеет цену в разработке), но реально она нужна для двух вещей: масштабирования и отказоустойчивости, при том второе не всегда верно, иногда лучше чтоб программа полностью грохнулась, чем обработала данные частично (разбиение на независимые модули с точки зрения разработки командой, возможность делать микросервисы и располагать их на разных машинах, что облегчает перезапуск системы в случае падения части сервисов и какую-то частичную работоспособность, по типу главная страничка работает, а вот вики нет). Крайне высокая связность - плохо (всегда плохо когда состояния 2 модулей связаны более чем в одном месте или связаны сложным образом через несколько других модулей, но это и дураку понятно). Но это вовсе не значит что надо упарываться и изобретать фреймворк и метапрограммирование на каждый чих. Нет, не надо. А вот у самой инверсии управления тоже есть свои недостатки: логика программы разбросана по куче мест (опять если цель делать бекдоры то это очень хорошо, вон в xz китайцы догадались аж в систему сборки логику бекдора всунуть, благо можно), поток управления неявный и использует общее состояние обработчиков событий, а это может быть плохо с точки зрения производительности, особенно в странных случаях, когда происходит что-то необычное.

Инверсия управления должна быть для уменьшения связности. Сама по себе низкая связность неплохо (хотя и имеет цену в разработке), но реально она нужна для двух вещей: масштабирования и отказоустойчивости, при том второе не всегда верно, иногда лучше чтоб программа полностью грохнулась, чем обработала данные частично (разбиение на независимые модули с точки зрения разработки командой, возможность делать микросервисы и располагать их на разных машинах, что облегчает перезапуск системы в случае падения части сервисов и какую-то частичную работоспособность, по типу главная страничка работает, а вот вики нет). Крайне высокая связность - плохо (всегдаа плохо когда состояния 2 модулей связаны более чем в одном месте или связаны сложным образом через несколько других модулей, но это и дураку понятно). Но это вовсе не значит что надо упарываться и изобретать фреймворк и метапрограммирование на каждый чих. Нет, не надо. А вот у самой инверсии управления тоже есть свои недостатки: логика программы разбросана по куче мест (опять если цель делать бекдоры то это очень хорошо, вон в xz китайцы догадались аж в систему сборки логику бекдора всунуть, благо можно), поток управления неявный и использует общее состояние обработчиков событий, а это может быть плохо с точки зрения производительности, особенно в странных случаях, когда происходит что-то необычное.