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

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

снижение рисков с помощью нарушения SOLID?

V>Я предполагаю, что внедрение зависимостей используется так: при запуске программы создаётся контейнер, в нём регистрируются сразу все компоненты, контейнер создаёт дерево зависимых компонентов, способное жить самостоятельно, и завершает свою работу (умирает). Компоненты далее работают сами по себе, не подозревая о наличии какого-то там контейнера.

Все красиво и есть прекрасный пример — COM. Но, увы я с уверенностью могу сказать, что в большинстве проектов до выделения компонентов дело просто не доходит... Проекты часто деградируют до крайне высокой стоимости поддержки и их или замораживают или переписывают с нуля. И в этом случае DI (как подход) имхо значительно увеличивает сложность систем на начальном уровне.

IQ>>Собственно ситуация имхо довольно типичная — мне то "опыт подказывает", а молодежь старательно "набивает шишки", но при этом, я почему-то сходу не нашел ни одного внятного объяснения от популяризаторов DI того, почему наивное использование DI будет провальным. Поэтому я решил таки сформулировать свой вариант

V>А как ещё учиться программистам? Только набивать шишки, анализировать свои ошибки, меняться.

В том то и парадокс, что проблемы DI почему-то не анализируют.

IQ>>Посмотрим на типичный пример наивного DI:
IQ>>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура? Как получилось, что попытка "соблюсти" принцип DIP очевидно вызывает нарушение всех остальных принципов SOLID и на это закрывают глаза? Как можно внедрять "зависимость сервиса" в ситуации, когда разработчик не способен создать сам внедряемый сервис? Проблема тут имхо базовая — разработчик не имеет навыков создания объектной декомпозиции и пытается компенсировать это использованием сложных механизмов, смысла которых он не понимает.

V>Разработчик рано или поздно избавится от этих кишок наружу — сначала спрячет их за фасадом, изолирует их, а потом ещё как-нибудь разделит — количество зависимостей между компонентами уменьшится. Но это уже мало имеет отношения к механизму внедрения зависимостей.

Т.е. возможно... в финале... разработчик исправит дефекты вызванные нарушением SOLID, спровоцированные наивным использованием DI. Но здесь имхо возникает онтологический разрыв — если разработчик способен понять, что его "наивный DI" был ошибкой, тогда почему он его в таком виде и написал? Т.е. чтобы перейти от наивного DI к компонентной архитектуре, от разработчика требуется имхо крайне серьезный профессиональный рос. Я не думаю, что это может произойти в течении неск. месяцев.

V>Плагины эти сначала надо научится выделять из кишков из примера выше. Сначала контроллер набирает кучу зависимостей, раздувается, потом становится ясно что некий кластер этих зависимостей сам по себе является компонентом, этот компонент отделяется, и контроллер начинает сдуваться — теперь у него всего пара зависимостей и он занимается только тем, чем и должен заниматься — управлять запросами и откликами.

V>Это процесс итеративный, главное не надо думать, что ясная архитектура должна рождаться сразу. Код должен писаться, а потом читаться и правиться. Только после серии правок начнёт вырисоваться внятная схема взаимодействия объектов.

Я это понимаю поэтому даже и думаю о DI на начальных стадиях, т.к. ничего кроме синтаксического оверхеда это не принесет.

V>Почему это названо проблемой конфигурации (внедрения зависимостей)? Конфигурация и архитектура не одно и то же.

В примере наивного DI который я привел, "внедрение зависимостей" доминирует над всем. И у этого кстати есть забавнейшее следствие — бизнес логика часто "выдавливается" "наивным DI" в клиентские javascript и в хранимые процедуры. Разработчик уже и сам чувствует, что "наивный DI" его ограничивает, но упорно от него не отказывается.

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

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

снижение рисков с помощью нарушения SOLID?

V>Я предполагаю, что внедрение зависимостей используется так: при запуске программы создаётся контейнер, в нём регистрируются сразу все компоненты, контейнер создаёт дерево зависимых компонентов, способное жить самостоятельно, и завершает свою работу (умирает). Компоненты далее работают сами по себе, не подозревая о наличии какого-то там контейнера.

Все красиво и есть прекрасный пример — COM. Но, увы я с уверенностью могу сказать, что в большинстве проектов до выделения компонентов дело просто не доходит... Проекты часто деградируют до крайне высокой стоимости поддержки и их или замораживают или переписывают с нуля. И в этом случае DI (как подход) имхо значительно увеличивает сложность систем на начальном уровне.

IQ>>Собственно ситуация имхо довольно типичная — мне то "опыт подказывает", а молодежь старательно "набивает шишки", но при этом, я почему-то сходу не нашел ни одного внятного объяснения от популяризаторов DI того, почему наивное использование DI будет провальным. Поэтому я решил таки сформулировать свой вариант

V>А как ещё учиться программистам? Только набивать шишки, анализировать свои ошибки, меняться.

В том то и парадокс, что проблемы DI почему-то не анализируют.

IQ>>Посмотрим на типичный пример наивного DI:
IQ>>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура? Как получилось, что попытка "соблюсти" принцип DIP очевидно вызывает нарушение всех остальных принципов SOLID и на это закрывают глаза? Как можно внедрять "зависимость сервиса" в ситуации, когда разработчик не способен создать сам внедряемый сервис? Проблема тут имхо базовая — разработчик не имеет навыков создания объектной декомпозиции и пытается компенсировать это использованием сложных механизмов, смысла которых он не понимает.

V>Разработчик рано или поздно избавится от этих кишок наружу — сначала спрячет их за фасадом, изолирует их, а потом ещё как-нибудь разделит — количество зависимостей между компонентами уменьшится. Но это уже мало имеет отношения к механизму внедрения зависимостей.

Т.е. возможно... в финале... разработчик исправит дефекты вызванные нарушением SOLID, спровоцированные наивным использованием DI. Но здесь имхо возникает онтологический разрыв — если разработчик способен понять, что его "наивный DI" был ошибкой, тогда почему он его в таком ошибочно виде внедрил? Т.е. чтобы перейти от наивного DI к компонентной архитектуре, от разработчика требуется имхо крайне серьезный профессиональный рост, а на это нужны годы.

V>Плагины эти сначала надо научится выделять из кишков из примера выше. Сначала контроллер набирает кучу зависимостей, раздувается, потом становится ясно что некий кластер этих зависимостей сам по себе является компонентом, этот компонент отделяется, и контроллер начинает сдуваться — теперь у него всего пара зависимостей и он занимается только тем, чем и должен заниматься — управлять запросами и откликами.

V>Это процесс итеративный, главное не надо думать, что ясная архитектура должна рождаться сразу. Код должен писаться, а потом читаться и правиться. Только после серии правок начнёт вырисоваться внятная схема взаимодействия объектов.

Я это понимаю поэтому даже и думаю о DI на начальных стадиях, т.к. ничего кроме синтаксического оверхеда это не принесет.

V>Почему это названо проблемой конфигурации (внедрения зависимостей)? Конфигурация и архитектура не одно и то же.

В примере наивного DI который я привел, "внедрение зависимостей" доминирует над всем. И у этого кстати есть забавнейшее следствие — бизнес логика часто "выдавливается" "наивным DI" в клиентские javascript и в хранимые процедуры. Разработчик уже и сам чувствует, что "наивный DI" его ограничивает, но упорно от него не отказывается.