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

IQ>А вы пост-то вообще читали? Смысл поста — обозначить очевидную проблему. В результате обсуждения, "адепты DI" наличие описанной в посте проблемы признавать отказались. Нет никакой проблемы, пишите как писали и не замарачивайтесь.

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

Процесс занимает 5-10 лет внимательного программирования.

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

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

IQ>>>>Вот нету у меня понимания примеров полезности DI. Все предлагают какой-то академический мусор за который в реальном проекте лупят ссаными тряпками. Да я сам похожий мусор когда-то плодил и довольно быстро увидел минусы. Плюсов пока разглядеть не получается, конечно я признаю, что повышение абстрактности кода потенциально полезно, но не понимаю — для чего, хотя я допускаю, что в некоторых проектах (которых я не видел) это может быть очень важно.
IQ>>·>Ага, понимания нет, но используешь что попалось под руку. На каком основании ты именно ambient context выбрал? Почему? Привычнее? Выбираешь сердцем?
IQ>>Я его не выбирал я использую решение 12 летней давности. Просто ambient context более подходит по описанию.
·>Повезло, что проект сильно не развивается 12 лет.

))) проектов более 20 3 из них введены в продакшен в этом году. EF, ajax, asp.net mvc все как надо.

IQ>>>>Пеар buzz на меня не действует.
IQ>>·>Ты даже чайнико-адаптированную книгу привёл с разжевыванием и примерами что и как делается, почему так делается и чем это грозит. Причём тут баззворды?
IQ>>При том, что на мой взгляд, "как надо" эти техники использоваться не будут...
·>Up to you. Причём тут техники?

Успех технологии определяется тем, способна ли большая часть инженеров освоить техники и эффективно их использовать...

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

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

Не спорю, DI всего лишь еще один важный повод.

IQ>>Совсем не понятно откуда такая уверенность.
·>Из моего опыта, я повидал и Spring разных версий, и Guice, и JBoss Seam, и доморощенный код на всяких синглтонах и прочих контекстах, и чисто java код, где даже большинство стандартных JDK-классов (типа String) не используется, и даже, прости господи, EJB. Так вот самый дубовый и простой в написании и поддержке код это именно DI+CI с явно выделенным composition root. К сожалению, делать просто — сложно, а делать сложно — просто.

))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.

IQ>>·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.
IQ>>Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.

Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.

·>В чём именно было улучшение-то от этого твоего отхреначивания?

Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя. Ну и количество интерфейсов уменьшилось на 90%

IQ>>>>Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
IQ>>·>Воплощение должно быть таким, чтобы код был всё ещё понимаемым и легко при желании изменяемым. Явные зависимости этому делу хорошо способствуют.
IQ>>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
·>Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.

Вы же сами ссылку на главу "6.4. Обсуждение феномена Constructor Over-injection" давали. Вы текст не читали что ли? Марк Симан по эстетическим причинам разговор про "Рефакторинг по направлению к Фасадным сервисам" завел?

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

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

IQ>>Забавный ответ от uncle Bob
IQ>>https://youtu.be/Nltqi7ODZTM?t=2025
IQ>>Я признаться был готов перестать его уважать, но после этого видео зауважал еще больше. Рекомендую смотреть сначала мне очень понравилось.
·>Он говорит о Dependency Injection Framework (ака IoC-container), то же самое, что я и писал в этом топике

Автор: ·
Дата: 01.09.16

.
·>Ты вот любишь свой Ambient Context, а ведь это тоже один из способов реализации Dependency Injection. Как же так позволил себе использовать DI?

А я не отрицаю, что использую топорную версию DI. Главное имхо то, что (на малых проектах) меня и менее умудренных коллег она ограничивает, в отличии от DI, с помощью которого, наивные энтузиасты творят ад.

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

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

IQ>>А вы пост-то вообще читали? Смысл поста — обозначить очевидную проблему. В результате обсуждения, "адепты DI" наличие описанной в посте проблемы признавать отказались. Нет никакой проблемы, пишите как писали и не замарачивайтесь.

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

V>Процесс занимает 5-10 лет внимательного программирования.

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

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

IQ>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>Не спорю, DI всего лишь еще один важный повод.
Повод для чего?

IQ>·>Из моего опыта, я повидал и Spring разных версий, и Guice, и JBoss Seam, и доморощенный код на всяких синглтонах и прочих контекстах, и чисто java код, где даже большинство стандартных JDK-классов (типа String) не используется, и даже, прости господи, EJB. Так вот самый дубовый и простой в написании и поддержке код это именно DI+CI с явно выделенным composition root. К сожалению, делать просто — сложно, а делать сложно — просто.
IQ>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.

IQ>>>·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.
IQ>>>Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
IQ>·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.
IQ>Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.
Изменяемые данные в статических полях есть? Значит глобальные и формально, и на самом деле.
В продуманной архитектуре зависимостей нет контекста, есть composition root.

IQ>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься. Это индикация, что ты толком не понимаешь что данный класс делает, ну и называешь его хелпер. Вот вспомним об SRP. Какая обязанность у хелпера?

IQ>Ну и количество интерфейсов уменьшилось на 90%
Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.

IQ>>>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
IQ>·>Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.
IQ>Вы же сами ссылку на главу "6.4. Обсуждение феномена Constructor Over-injection" давали. Вы текст не читали что ли? Марк Симан по эстетическим причинам разговор про "Рефакторинг по направлению к Фасадным сервисам" завел?
Ты похоже вообще не читал, почитай, таки да, по эстетическим:

Тем не менее, некоторым людям неудобно, если число зависимостей растет. Они не любят конструкторы со слишком большим числом параметров.

Мало того, что DI+CI тут не причём, т.к.

Этот плохо пахнущий код не появляется, но усугубляется в результате использования DI

Вместо того чтобы чувствовать неловкость из-за Constructor Over-injection, мы должны принять его как удачный побочный эффект внедрения в конструктор. Это сигнал, который предупреждает нас всякий раз, когда класс берет на себя слишком большую ответственность.

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

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

IQ>>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>>Не спорю, DI всего лишь еще один важный повод.
·>Повод для чего?

Плодить интерфейсы

IQ>>·>Из моего опыта, я повидал и Spring разных версий, и Guice, и JBoss Seam, и доморощенный код на всяких синглтонах и прочих контекстах, и чисто java код, где даже большинство стандартных JDK-классов (типа String) не используется, и даже, прости господи, EJB. Так вот самый дубовый и простой в написании и поддержке код это именно DI+CI с явно выделенным composition root. К сожалению, делать просто — сложно, а делать сложно — просто.
IQ>>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
·>Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.

Любая, самая идеальная вещь может быть плохой там, где она лишняя.

IQ>>>>·>Написано же в книге, что сам по себе такой конструктор проблем не создаёт, просто страдает эстетика, но код всё равно относительно легко контролируется и понимается.
IQ>>>>Ох... ну раз в книге написано, значит г..нопроектов откуда я отхреначивал наивный DI не было, может они мне приснились...
IQ>>·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.
IQ>>Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.
·>Изменяемые данные в статических полях есть? Значит глобальные и формально, и на самом деле.

В статических полях исключительно stateless сервисы. Изменяемые данные в local context. Это или thread contect или httpcontext.

·>В продуманной архитектуре зависимостей нет контекста, есть composition root.

Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.

IQ>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.

Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.

·>Это индикация, что ты толком не понимаешь что данный класс делает, ну и называешь его хелпер. Вот вспомним об SRP. Какая обязанность у хелпера?

Обязанность хелпера — быть помойкой хелперных методов

IQ>>Ну и количество интерфейсов уменьшилось на 90%
·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.

Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны. Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.

IQ>>>>Вот эти вынужденные фасады над фасадами над фасадами это "понимаемо" и "легко изменяемо"?
IQ>>·>Что значит вынужденные? Если они вынуждены, то дело не в CI, а с твоими любимыми глобальными переменными получится амбиентные синглтоны провайдеров фабрики синглтонов контекстов.
IQ>>Вы же сами ссылку на главу "6.4. Обсуждение феномена Constructor Over-injection" давали. Вы текст не читали что ли? Марк Симан по эстетическим причинам разговор про "Рефакторинг по направлению к Фасадным сервисам" завел?
·>Ты похоже вообще не читал, почитай, таки да, по эстетическим:
·>

Тем не менее, некоторым людям неудобно, если число зависимостей растет. Они не любят конструкторы со слишком большим числом параметров.

·>Мало того, что DI+CI тут не причём, т.к.
·>

Этот плохо пахнущий код не появляется, но усугубляется в результате использования DI

·>

Вместо того чтобы чувствовать неловкость из-за Constructor Over-injection, мы должны принять его как удачный побочный эффект внедрения в конструктор. Это сигнал, который предупреждает нас всякий раз, когда класс берет на себя слишком большую ответственность.

Ладно, оставим это все на совести адептов DI. Собсна цель моего поста не в том, чтобы запрещать им ковырять в носу.

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

IQ>>>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>>>Не спорю, DI всего лишь еще один важный повод.
IQ>·>Повод для чего?
IQ>Плодить интерфейсы
Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.

IQ>>>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
IQ>·>Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.
IQ>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
Так отказывайся от ambient context. Он лишний же.

IQ>>>·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.
IQ>>>Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.
IQ>·>Изменяемые данные в статических полях есть? Значит глобальные и формально, и на самом деле.
IQ>В статических полях исключительно stateless сервисы. Изменяемые данные в local context. Это или thread contect или httpcontext.
TLS это то же статическое поле, по сути это статическая мапа с локами, где где ключом является currentThreadId. Глобальная переменная, перенесённая под реалии многопоточного программирования. httpcontext.current это тоже TLS.

IQ>·>В продуманной архитектуре зависимостей нет контекста, есть composition root.
IQ> Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.

IQ>>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
IQ>·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.
IQ>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
Так куда эта паутина зависимостей делась? Замели под коврик?
Зашли в тёмный подвал, включили свет — ух сколько грязи и паутины, давайте лучше лампочку разобьём, чтобы этого ничего не было видно, ну и напишем пост "О наивном освещении в подвале".

IQ>>>Ну и количество интерфейсов уменьшилось на 90%
IQ>·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.
IQ>Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны.
Вот же: http://rsdn.org/forum/design/6560633.flat#6560633

Автор: ·
Дата: 22.09.16

Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
Спасибо, что ты наконец-то решил почитать что тут пишут.

IQ>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.

IQ> Ладно, оставим это все на совести адептов DI. Собсна цель моего поста не в том, чтобы запрещать им ковырять в носу.
Ты не отмахивайся, а читай и борись с невежеством, а не с DI.

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

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

IQ>>>>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>>>>Не спорю, DI всего лишь еще один важный повод.
IQ>>·>Повод для чего?
IQ>>Плодить интерфейсы
·>Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.

Марк Симан невежество, не я сказал...

IQ>>>>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
IQ>>·>Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.
IQ>>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
·>Так отказывайся от ambient context. Он лишний же.

Он собственно появился по одной простой причине — сугубо синтаксическая группировка всех часто используемых сервисов. Его можно смело выкинуть и создавать все нужные сервисы с помощью new.

IQ>>·>В продуманной архитектуре зависимостей нет контекста, есть composition root.
IQ>> Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
·>Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.

Имхо если мало знаний нефиг принимать серьезные решения.

IQ>>>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
IQ>>·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.
IQ>>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
·>Так куда эта паутина зависимостей делась? Замели под коврик?

Эта паутина, в данном конкретном случае, никогда никого не интересовала (и до сих пор не интересует). Как например и clr code проекта или как sql сервер парсит запросы и т.д. В этом мире прорва вещей детали которых здесь и сейчас абсолютно не важны.

IQ>>>>Ну и количество интерфейсов уменьшилось на 90%
IQ>>·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.
IQ>>Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны.
·>Вот же: http://rsdn.org/forum/design/6560633.flat#6560633

Автор: ·
Дата: 22.09.16

·>Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
·>Спасибо, что ты наконец-то решил почитать что тут пишут.

Ну вы уж совсем меня за хейтера держите. О DI читал очень давно и сперва мне показалось, что из за ада с интерфейсами никто его использовать не будет. И так я думал до тех пор, пока меня не подключили к загибавшемуся проекту где бедолага программер просто утонул в зависимостях которые сам наплодил и конечно же он понятия не имел нафига они ему нужны в ядре бизнес логики, которое нужно исключительно для 1 проекта.

IQ>>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
·>Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.

Хотя бы раз назовите фреймворк, который используете. В composition root регистрируются сервисы с клиентами кто их связывает? Что такое CI (constructor injection)? Кто/что вам его предоставляет?

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

IQ>>>Плодить интерфейсы
IQ>·>Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.
IQ>Марк Симан невежество, не я сказал...
"Требовать" и "предлагать" — несколько разные вещи. Да, какие-то аспекты архитектуры требуют интерфейсов, но это не DI.

IQ>>>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
IQ>·>Так отказывайся от ambient context. Он лишний же.
IQ>Он собственно появился по одной простой причине — сугубо синтаксическая группировка всех часто используемых сервисов. Его можно смело выкинуть и создавать все нужные сервисы с помощью new.
Хорошо, но уже лучше. Правильно, можно выкинуть. Осталось выделить все эти new в отдельный код, называемый composition root и получится DI здорового человека.

IQ>>> Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
IQ>·>Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.
IQ>Имхо если мало знаний нефиг принимать серьезные решения.
Хм... Как мило.
Т.е. применить ambient context это несерьёзное решение:

Правильная реализация Ambient Context может оказаться непростой задачей.

а вот constructor injection это серьёзное решение:

... если есть сомнения, выберите внедрение в конструктор: вы никогда сильно не ошибетесь в этом выборе. ... Его легче понять и проще надежно реализовать, чем любой из других DI паттернов. Вы можете построить целые приложения только с одним внедрением в конструктор

IQ>>>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
IQ>·>Так куда эта паутина зависимостей делась? Замели под коврик?
IQ>Эта паутина, в данном конкретном случае, никогда никого не интересовала (и до сих пор не интересует). Как например и clr code проекта или как sql сервер парсит запросы и т.д. В этом мире прорва вещей детали которых здесь и сейчас абсолютно не важны.
Правильно, зачем думать — прыгать надо.

IQ>·>Вот же: http://rsdn.org/forum/design/6560633.flat#6560633

Автор: ·
Дата: 22.09.16

IQ>·>Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
IQ>·>Спасибо, что ты наконец-то решил почитать что тут пишут.
IQ> Ну вы уж совсем меня за хейтера держите. О DI читал очень давно и сперва мне показалось, что из за ада с интерфейсами никто его использовать не будет. И так я думал до тех пор, пока меня не подключили к загибавшемуся проекту где бедолага программер просто утонул в зависимостях которые сам наплодил и конечно же он понятия не имел нафига они ему нужны в ядре бизнес логики, которое нужно исключительно для 1 проекта.
Что ты читал? И где там написано, что интерфейсы обязательны?

IQ>>>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
IQ>·>Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.
IQ>Хотя бы раз назовите фреймворк, который используете.
Никакой, plain java.

IQ>В composition root регистрируются сервисы с клиентами кто их связывает?
В composition root никто не регистрируется, какие ещё сервисы-клиенты? Твой вопрос не имеет смысла, т.к.

A Composition Root is a (preferably) unique location in an application where modules are composed together.

Пример по ссылке выше, в конце сообщения.

IQ>Что такое CI (constructor injection)?
Передача зависимостей в конструктор объекта. Пример там же. Ну и в твоём талмуде.

IQ>Кто/что вам его предоставляет?
Java Language Specification.

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

IQ>>В composition root регистрируются сервисы с клиентами кто их связывает?
·>В composition root никто не регистрируется, какие ещё сервисы-клиенты? Твой вопрос не имеет смысла, т.к.
·>

A Composition Root is a (preferably) unique location in an application where modules are composed together.

·>Пример по ссылке выше, в конце сообщения.

IQ>>Что такое CI (constructor injection)?
·>Передача зависимостей в конструктор объекта. Пример там же. Ну и в твоём талмуде.

Это не мой талмуд, это талмуд Марка Симана.

IQ>>Кто/что вам его предоставляет?
·>Java Language Specification.

Э... т.е. вы создаете все сервисы и все связи на старте приложения операцией new? И потом все их скопом передаете в какой-то диспечер бизнес логики, который их хранит и подставляет в вызовы бизнес операций?

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

IQ>>>Кто/что вам его предоставляет?
IQ>·>Java Language Specification.
IQ>Э... т.е. вы создаете все сервисы и все связи на старте приложения операцией new? И потом все их скопом передаете в какой-то диспечер бизнес логики, который их хранит и подставляет в вызовы бизнес операций?
Создаём. Непонятно — что такое диспечер бизнес-логики?
Может быть какой-то фреймворк для взаимодействия с внешним миром. В одном приложении далеко не всегда такой фреймворк единственный. там может и какой-нибуь messaging с UDP-сокетами, или субд api.
Скажем веб-сервер это такой фреймворк, который публикует какие-то объекты как доступные по некоему url. Вот например, классическое web-приложение с субд и Web Server (Jetty).

public static void main(String args[])
{
...
        DbConnection dbConnection = new DbConnection(connectionString);
        OurServiceHttpHandler ourServiceHttpHandler = new OurServiceHttpHandler(dbConnection);
...

        ContextHandler ourServiceContext = new ContextHandler("/ourService");
        ourServiceContext.setHandler(ourServiceHttpHandler);

        Server server = new Server(httpPortNumber);
        server.setHandler(ourServiceContext);

        // Start the server
        server.start();
        server.join();
}

Только это всё инфраструктура, а не бизнес-логика.

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

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

IQ>>>>Кто/что вам его предоставляет?
IQ>>·>Java Language Specification.
IQ>>Э... т.е. вы создаете все сервисы и все связи на старте приложения операцией new? И потом все их скопом передаете в какой-то диспечер бизнес логики, который их хранит и подставляет в вызовы бизнес операций?
·>Создаём.

В общем и целом в финале выяснилось, что я сплошь и рядом использую constructor Dependency Injection да еще и с ambient context (пусть и самодельным), без DI фреймворков, ненужных интерфейсов и прочих code-перделок. Найду краткий материал, который наглядно это показал и впишу выводы в пост.

PS Интересный момент... Имхо DI без фреймворков, на моей памяти не провоцировал разработчиков делать сервис из любого мусора по любому поводу. Мусор закономерно отправлялся в хелперы где справедливо служил источником code smell.

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

IQ>В общем и целом в финале выяснилось, что я сплошь и рядом использую constructor Dependency Injection да еще и с ambient context (пусть и самодельным), без DI фреймворков, ненужных интерфейсов и прочих code-перделок. Найду краткий материал, который наглядно это показал и впишу выводы в пост.

Обновил.

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

IQ>>В общем и целом в финале выяснилось, что я сплошь и рядом использую constructor Dependency Injection да еще и с ambient context (пусть и самодельным), без DI фреймворков, ненужных интерфейсов и прочих code-перделок. Найду краткий материал, который наглядно это показал и впишу выводы в пост.
IQ>Обновил.
Добро пожаловать в секту. Му-ха-ха!!!

А троллить ты первый начал со своей Colonoscopy Injection. Хотя... какой rsdn без троллинга...

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

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

IQ>>>В общем и целом в финале выяснилось, что я сплошь и рядом использую constructor Dependency Injection да еще и с ambient context (пусть и самодельным), без DI фреймворков, ненужных интерфейсов и прочих code-перделок. Найду краткий материал, который наглядно это показал и впишу выводы в пост.
IQ>>Обновил.
·>Добро пожаловать в секту. Му-ха-ха!!!

Не оказалось секта прячется в тени DI.

·>А троллить ты первый начал со своей Colonoscopy Injection.

И до сих пор считаю это определение годным конечно относительно стиля навязываемого DI фреймворками.

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

EP>Видимо "параметр" звучит недостаточно солидно и паттерново

Это специфический параметр, за который можно дергать кого-то третьего. ))

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

EP>>Видимо "параметр" звучит недостаточно солидно и паттерново
V>Это специфический параметр, за который можно дергать кого-то третьего. ))

Callback жеж

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

EP>>>Видимо "параметр" звучит недостаточно солидно и паттерново
V>>Это специфический параметр, за который можно дергать кого-то третьего. ))
EP>Callback жеж

Тут терминология от философии конкретного этого места зависит.

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

А если этот колбэк или интерфейс используется для получения от третьих лиц неких данных или абстрактных объектов, то это уже DI.

Понятно, что техника и там и там одинакова — это вызов ф-ии по косвенному адресу (единичной или в составе интерфейса).

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

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

vsb>>>Так что вы предлагаете, учитывая, что тестировать надо? Я пока ничего лучше DI не видел.

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

vsb>Но ведь юнит-тестирование это стандарт-де факто в современном софтостроении. Писать софт без тестов это как пользоваться винраром для контроля версий.

Если речь только про юнит тесты, посмотрите в сторону Microsoft Fakes или аналогов. Из коробки дает доступ к приватным и статическим членам, гененрируя свой Мок-класс обертку.