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

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

IT>Ты видимо прочитал лишь то, что хотел. Это бывает. Объясняю ещё раз. В случае DI объект получает не весь необходимый контекст, а вообще всё, что можно.

Если объект тащит все что можно, то он и получит все что надо.

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

У тебя одна строчка и сразу целый вагон всего Я пока на своем примере покажу, ты все равно ничего путного пока не привел

понять что именно объекту нужно, а что ему передали просто нереально
Понять, что нужно объекту очень легко — все это в описании его публичного интерфейса, обычно проперти и конструктор. Что передали — это в конфигурации DI, кроме аргументов конкретной операции. Что может передаваться в аргументах показыва Find Usages у интерфейса.

Есть проблема, вот эти самые Find Usages, если базовй метод используется очень часто, то поиск по ём ничего не даст, надо искать ссылки на интерфейс и анализировать использование этих ссылок. Здесь проблема с привидением интерфейса к базовым типам.

требуется отчуждение кода от системы

Сложность отчуждения в зависимости от
A. количества депенденсов. Если компонент требует вагон депенденсов, то отчуждение это боль и DI не поможет, т.к. проблема в большом количестве депенденсов.
SRP не помогает, тупо вместо одного компонента станет пачка, но вся эта пачка будет тащить суммарно все те же депенденсы, что и большой компонент.
B. Управления депенденсами. Если депенденсы оформлены явно и нет всевозможных прямых ссылок, ссылок на God Object, Dependency Pack, Context with All dependencies, то отчуждение довольно простое, при условии что компонент заточен под DI.

При чем, п.A дает сильно нелинейную зависимость. Скажем, я в своем примере совершенно не представляю как можно отчуждать компоненты вроде OpenDocumentCommand. Скажем, простейший воркфлоу такой:
0. закрыть текущий документ — депенденс на соответствующую команду, DI
1. найти пекадж, раззиповать, определить формат и версию — целых три депенденса, тащится напрямую
2. проверить лицензию — тоже депенденсы, DI
3. провалидировать кое какие свойтсва , значть открыть часть данных — еще около трех депенденсов, все DI
4. показать форму для недостающих пропертей — депенденс на форму — DI
5. вычислить недостающие вычислимые проперти — депенденс на сервис который выполнит эту операцию по конкретному конфигу DI
6. загрузить сам пекадж — собственно депенденсы в зависимости от формата, загрузчик, все руками напрямую
7. добавить документ в MRU — депенденсы на модель приложения
8. Вся хрень делается в фоне, стало быть депенденсы на бекграунд воркер, который умеет с прогресом работать. Операцию можно откатить- есть депенденсы соответсвующие. Эта хрень захардкожена, ибо так проще, все под рукой.

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

Парадокс — теоретически, можно обрезать депенденсы и довольно просто. Толко после этого почти ничего не останется, получится некоторый конвейер из операций. Парадокс — почти весь код команды почти без изменений уйдет в конфигурирование DI, ибо отчуждаемой частью станет только сам конвейер и базовые вещи, которые сами не имеют депенденсов, типа зиппер и тд. Фокус в том, что такой конвейер станет еще тяжелее обслуживать.

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

при его рефакторингах и модификациях,
Сложность рефакторинга и модификации зависит от
1 количества и качества депенденсов.
2 количества и качества обязанностей

Лично я отчуждаемый код делаю не иначе как с помощью обрезания депенденсов. Без этого компоненты можно отчуждать только наполовину, для использования в родственном проекте.
Правда часто случается так, что после обрезания депенденсов ничего не остаётся. Там, где для задачи требуется вагон депенденсов совершенно не ясно что делать.
DI может помочь с диспетчеризацией, но отчуждение все равно будет АДъ и Израиль.

Здесь нужен конкретный пример от тебя, правда я не уверен, что смогу быстро вникнуть в твою проблему, у меня пока что нет скилов решать любые проблемы за время написания сообщения на форуме


I>>Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"

IT>Вас очень сложно тролить. На любое моё "покажите код" у вас один ответ — "ты не понимаешь".

Я ж показал код Ссылку на репозиторий тебе дать чтоли ?

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

I>Практически именно то, для чего и нужен DI — дать возможность компоненту при вызове получать весь необходимый контекст.
I>Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"

Что-то мне подсказывает, что под DI он понимает Service Locator. То да, тогда будет все как он пишет — и проброс всего и вся внутрь, и муторные попытки понять что именно требует тот или иной класс.

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

I>>Практически именно то, для чего и нужен DI — дать возможность компоненту при вызове получать весь необходимый контекст.
I>>Вобщем, после таких слов для тебя самый удобный вариант это : "Заканчиваю троллить, иду работать"

Doc>Что-то мне подсказывает, что под DI он понимает Service Locator. То да, тогда будет все как он пишет — и проброс всего и вся внутрь, и муторные попытки понять что именно требует тот или иной класс.

Чтото навроде.

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

IT>Ты видимо прочитал лишь то, что хотел. Это бывает. Объясняю ещё раз. В случае DI объект получает не весь необходимый контекст, а вообще всё, что можно. При этом понять что именно объекту нужно, а что ему передали просто нереально. Поэтому при изучении кода, при его рефакторингах и модификациях, в случаях когда требуется отчуждение кода от системы, работа с таких кодом превращается в одну сплошную невыносимую головную боль.

То, о чем вы говорите, по описанию похоже на Service Locator, который действительно хренов.
Но ведь Dependency Injection возможно реализовать, например, как Constructor Injection, т.е. все зависимости получаются через конструктор. и сразу видно, что класс требует. Тут свой недостаток тоже будет — если это делается с использованием IoC-контейнера, то поиск по вызову конструктора класса ничего не найдет.

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

IT>>Ты видимо прочитал лишь то, что хотел. Это бывает. Объясняю ещё раз. В случае DI объект получает не весь необходимый контекст, а вообще всё, что можно. При этом понять что именно объекту нужно, а что ему передали просто нереально. Поэтому при изучении кода, при его рефакторингах и модификациях, в случаях когда требуется отчуждение кода от системы, работа с таких кодом превращается в одну сплошную невыносимую головную боль.

L>То, о чем вы говорите, по описанию похоже на Service Locator, который действительно хренов.
L>Но ведь Dependency Injection возможно реализовать, например, как Constructor Injection, т.е. все зависимости получаются через конструктор. и сразу видно, что класс требует. Тут свой недостаток тоже будет — если это делается с использованием IoC-контейнера, то поиск по вызову конструктора класса ничего не найдет.
Dependency Injection и Service Locator это 2 противоположных решения задачи связывания зависимостей. Как это можно путать? DI — в объект инжектят зависимости (constructor/field/method injection), а SL — есть глобальный реестр из которого запрашиваются зависимости (выше по топику "var cmd = Resolve<ICommandYYY<TArgs>>();").
Просто большинство IoC-контейнеров обычно предоставляют и DI, и SL. Видимо, некоторые этого не понимают и юзают корявый SL, но почему-то называют это DI, излучая лучи поноса.

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

.>Dependency Injection и Service Locator это 2 противоположных решения задачи связывания зависимостей. Как это можно путать?

Это вы мне? Я их не путаю.

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

D>Можно пример проблемы именно из-за DI?

Легко. Вот пилю сейчас часть проекта, где запихнули MEF куда только можно. Решил попользовать готовый объект, часть ДАЛа, что б не городить велосипед самому. Пишу как положено — new бла-бла-бла. Вроде все создается и даже работает. Потом хочу дернуть нужное свойство и бац все падает в рантайме. Начинаю копать код, а там оказывается куча непубличных полей, которые инициализируются через рефлекшн МЕФом и которые никак по другому не проинициализировать, а тащить весь контекст приложения, туда где он не нужен — зло. Понятно, проблема не напрямую в DI, а в дизайне, но такие дизайны сплошь и рядом. Хотя по рукам надо бить и MS, которая такие финты позволяет. Возникают сложности там где не нужно, в итоге нормальной с первого взгляда объект можно использовать без лишнего геммороя только в единственном месте, там где это задумал мегаархитектор.

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

D>>Можно пример проблемы именно из-за DI?
A>Легко. Вот пилю сейчас часть проекта, где запихнули MEF куда только можно. Решил попользовать готовый объект, часть ДАЛа, что б не городить велосипед самому. Пишу как положено — new бла-бла-бла. Вроде все создается и даже работает. Потом хочу дернуть нужное свойство и бац все падает в рантайме. Начинаю копать код, а там оказывается куча непубличных полей, которые инициализируются через рефлекшн МЕФом и которые никак по другому не проинициализировать, а тащить весь контекст приложения, туда где он не нужен — зло. Понятно, проблема не напрямую в DI, а в дизайне, но такие дизайны сплошь и рядом. Хотя по рукам надо бить и MS, которая такие финты позволяет. Возникают сложности там где не нужно, в итоге нормальной с первого взгляда объект можно использовать без лишнего геммороя только в единственном месте, там где это задумал мегаархитектор.
И причём тут архитектура? Так, синтаксис немного неудобный для кривого использования.
Если тебе так хочется использовать new и религия не позволяет использовать IoC-контейнер, то можно слегка отрефакторить: переделать field injection в constructor injection (и это правильно), в общем всё. Или даже просто объявить поля публичными, чтобы насладиться ручным DI.

IT>Я уже устал об этом говорить. DI ломает навигацию по проекту
В 2003 году? В 2013 не ломает, если вы используете правильные инструменты (при программировании в блокноте, согласен, навигация никакая, даже без DI).

IT>Бизнес логика разбивается на части и разносится по разным частям приложения.
Это проблема не DI, а криворукого архитектора. Мне понятна ваша боль по поводу говнокода, однако вы ошибочно ее приписываете не тому адресату. Если человеку религия не позволяет писать new в проекте с DI, отказ от DI проблему не решит, потому что упоротые псевдоархитекторы всегда найдут, чем заморочиться. Они напишут свой DI на self-managed singletons, с разливным пивом, рефлексией и марусями, накидают сотню фабрик и адаптеров, конфигурируемых в XML, просто потому, что не освоили ООП перед чтением GoF. Но это не проблема библиотек, это проблема общего дефицита кадров в нашей индустрии и некомпетентности сениоров и архитектов, получивших свою позицию, в лучшем случае, по выслуге лет, а то и просто потому, что за пару лет после выпуска из института успели пройти по верхам десяток фреймворков. Применять NIH-подход и отказываться от лучших практик отрасли только поэтому — это лишь ухудшать ситуацию.

IT>Это затрудняет модификацию приложения.
Первый способ борьбы со сложностью модификации в крупном проекте — бить на сущности и выделять интерфейсы. Правильно распиленную, а потому слабо связанную систему проще модифицировать и тестировать, потому что низка вероятность побочных эффектов. Как только у вас вместо одного черт-ногу-сломит-объекта появилось два объекта попроще, у вас возникла задача связывания, с которой связан второй способ уменьшения сложности. Вы либо решаете её самостоятельно (и нет гарантии, что вы решите ее лучше, чем это сделали до вас), либо используете готовое решение, которое стоимость поддержки снижает, поскольку а) является типовым, б) вероятно известно и другим разработчикам, а значит не требует времени на обучение и снижает риски проекта.

IT>А всегда ли это нужно?
В проекте объемом больше пары десятков тысяч строк — да, уже имеет смысл. На всяких мелких — не обязательно, но по рельсам паровоз обычно едет лучше, чем по говну.

Здравствуйте, IT, Вы писали:
IT>Валидация — это часть логики, какой-то тут DI?
Вы тесты в своей жизни когда-нибудь писали или отдаёте на продакшн кота в мешке, прощупанного за яйца Равичандрой из QA (но, поскольку кот — в мешке, Равичандра уверен, что это персики, как и сказано в техзадании)?

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

D>>Можно пример проблемы именно из-за DI?
IT>Я уже устал об этом говорить. DI ломает навигацию по проекту, что существенно затрудняет читабельность и понимабильность кода приложения.
Каким образом? Если вы начинаете на каждый чих создавать интерфейсы, то причём тут DI? Контейнерам не нужны интерфейсы (только если AOP требуется, но причём тут DI?), они могут и простые классы инжектить.

IT> Бизнес логика разбивается на части и разносится по разным частям приложения. Это затрудняет модификацию приложения.
А можно пример? Каким образом тут DI приплетён? Если вдруг после того как зависимости стали делать управляемыми, ВНЕЗАПНО стало заметно, что у какого-то класса 50 зависимостей, 10000 строк кода и 0 юнит-тестов, то это не вина DI.

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

Автор: IT
Дата: 13.10.13

.

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

CEM>Вот интересно, кто как и на основе чего в своей работе руководствуется при таком выборе?

Не буду говорить за всех, но у меня очень часто получалось, что в сторонней библиотеке вылезает какой-нибудь мутный баг, на отладку и выяснение причин уходит куча времени, пытаюсь достучаться до авторов, они сначала упираются рогом и заявляют что никакого бага нет, потом я заваливаю их доказательствами (и трачу на их сбор кучу времени), они наконец понимают что накосячили и обещают исправить "когда-нибудь потом", или исправляют один баг и добавляют два новых), я трачу еще время на попытку обойти баг, потом наконец плюю на все, делаю свой заменитель и наконец радуюсь жизни — минус время и нервы.

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

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

.>И причём тут архитектура? Так, синтаксис немного неудобный для кривого использования.

Да при том, что объект заранее спроектирован криво и расчитан на использование костылей, которые допускает в данном случае MEF.

.>Если тебе так хочется использовать new и религия не позволяет использовать IoC-контейнер, то можно слегка отрефакторить: переделать field injection в constructor injection (и это правильно), в общем всё. Или даже просто объявить поля публичными, чтобы насладиться ручным DI.

Мне религия не позволяет городить тонну кода на ровном месте. По сути мне нужно было написать крохотную dll, которая будет дергаться планировщиком, выполнять несколько хранимок и писать в базу результаты. Там кода на 100-200 строк, поэтому и решил использовать объект из основного проекта, который позволяет сконфигурировать все эти вызовы и буквально одной строкой получать данные. Так вот, из-за кривости реализации ты мне предлагаешь тащить кучу доп. зависимостей и сделать "как правильно", вместо того, что бы сделать как проще и понятнее.

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

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

A>Да при том, что объект заранее спроектирован криво и расчитан на использование костылей, которые допускает в данном случае MEF.
Допустим, что было спроектировано криво, костылесовместимость решений от M$ всегда высока, поубивав бы. Но тебе понадобился лишь элементарный рефакторинг с минимальным импактом, чтобы это поправить. Если бы не было явного DI, то скорее всего была бы мешанина ещё более кривых архитектурных решений, такие как рассыпанные по всему коду класса операторы new, глобальные синглтоны, статические фабрики, магические контексты и прочий шлак, рефакторинг которого довльно сложная задача со слабо предсказуемыми последствиями.

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

.>>Если тебе так хочется использовать new и религия не позволяет использовать IoC-контейнер, то можно слегка отрефакторить: переделать field injection в constructor injection (и это правильно), в общем всё. Или даже просто объявить поля публичными, чтобы насладиться ручным DI.

A>Мне религия не позволяет городить тонну кода на ровном месте. По сути мне нужно было написать крохотную dll, которая будет дергаться планировщиком, выполнять несколько хранимок и писать в базу результаты. Там кода на 100-200 строк, поэтому и решил использовать объект из основного проекта, который позволяет сконфигурировать все эти вызовы и буквально одной строкой получать данные. Так вот, из-за кривости реализации ты мне предлагаешь тащить кучу доп. зависимостей и сделать "как правильно", вместо того, что бы сделать как проще и понятнее.
Я не знаю как там в C# мире, но в Яве чтобы минимально заюзать DI нужно добавить ~500k либу и написать пол дюжины строк кода. И объём этого кода будет явно меньше, чем если бы конфигурировал эти все вызовы вручную.

A>Проблему я конечно же решил в течении пары часов, просто дополнил контсруктор инициализацией нужных полей и добавил в код несколько проверок. Я просто хотел показать и ответить на вопрос, что вот она конкретная проблема, вызванная чрезмерной увлеченностью DI. А был бы на моем месте другой, точно бы нагородил кучу нечитаемого кода, но сделал бы все по паттернам.
Понимаю, можно что угодно нагородить где угодно, но DI в этом скорее будет мешать.
Не понимаю из твоего рассказа почему ты решил, что эта проблема вызвана DI.

Что-то мне кажется, что все эти нападки направлены на что угодно, но не DI. DI это очень тривиальный и маленький паттерн, альтернативы ему — сложнее или кривее.
В общем вот почитай: http://code.google.com/p/google-guice/wiki/Motivation и выскажи что такого неправильного в предложенном решении c DI и как бы ты сам решал такую задачу.

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

L>То, о чем вы говорите, по описанию похоже на Service Locator, который действительно хренов.

О! ServiceLocator — это вообще круто, особенно, когда некоторые умельцы используют его совместно с DI

L>Но ведь Dependency Injection возможно реализовать, например, как Constructor Injection, т.е. все зависимости получаются через конструктор. и сразу видно, что класс требует. Тут свой недостаток тоже будет — если это делается с использованием IoC-контейнера, то поиск по вызову конструктора класса ничего не найдет.

Во-первых, IoC. Во-вторых, как правило передаваемый интерфейс не содержит в себе один единственный метод. Чаще всего это целая гроздь? зачастую слабосвязанных друг с другом методов, у которых свои собственные зависимости. И среди этих зависимостей могут легко оказаться зависимости никак не связанные с целевым объектом. Этого сложно избежать, даже если за этим строго следить. А так как это вообще-то нафиг никому не нужно, то имеет то, что имеем. А именно сложно отчуждаемый код, котоый выдрать из контекста можно только с мясом.

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

IT>>Валидация — это часть логики, какой-то тут DI?
B>Вы тесты в своей жизни когда-нибудь писали или отдаёте на продакшн кота в мешке, прощупанного за яйца Равичандрой из QA (но, поскольку кот — в мешке, Равичандра уверен, что это персики, как и сказано в техзадании)?

Ты что-то хотел сказать?

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

IT>>Я уже устал об этом говорить. DI ломает навигацию по проекту
B>В 2003 году? В 2013 не ломает, если вы используете правильные инструменты (при программировании в блокноте, согласен, навигация никакая, даже без DI).

Сколько пафоса! Можно подумать ты пишешь программы с помощью мысленного инструмента, а не с помощью клавиатуры.

IT>>Бизнес логика разбивается на части и разносится по разным частям приложения.
B>Это проблема не DI, а криворукого архитектора.

Если очень хочется пообсуждать криворукость архитектуры и архитекторов, то достаточно показать здесь свой наиправильнейший код. Или слабо?

IT>>А всегда ли это нужно?
B>В проекте объемом больше пары десятков тысяч строк — да, уже имеет смысл. На всяких мелких — не обязательно, но по рельсам паровоз обычно едет лучше, чем по говну.

Ничего не понял Какой паровоз...

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

IT>>Я уже устал об этом говорить. DI ломает навигацию по проекту, что существенно затрудняет читабельность и понимабильность кода приложения.
.>Каким образом? Если вы начинаете на каждый чих создавать интерфейсы, то причём тут DI? Контейнерам не нужны интерфейсы (только если AOP требуется, но причём тут DI?), они могут и простые классы инжектить.

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

IT>> Бизнес логика разбивается на части и разносится по разным частям приложения. Это затрудняет модификацию приложения.
.>А можно пример? Каким образом тут DI приплетён? Если вдруг после того как зависимости стали делать управляемыми, ВНЕЗАПНО стало заметно, что у какого-то класса 50 зависимостей, 10000 строк кода и 0 юнит-тестов, то это не вина DI.

При чём тут количество зависимосей, объём коди и юнит тесы?

IT>>А всегда ли это нужно?
.>Чаще чем не нужно, если ты пишешь что-то сложнее, чем фреймворк для умножения двух чисел

Автор: IT
Дата: 13.10.13

.

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

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

IT>>>Я уже устал об этом говорить. DI ломает навигацию по проекту, что существенно затрудняет читабельность и понимабильность кода приложения.
.>>Каким образом? Если вы начинаете на каждый чих создавать интерфейсы, то причём тут DI? Контейнерам не нужны интерфейсы (только если AOP требуется, но причём тут DI?), они могут и простые классы инжектить.
IT>Вообще-то смысл DI в устранении зависимостей от реализации, т.е. в использовании интерфейсов вместо классов.
Да, а реализация определяется только оператором new. Если используется класс, то всегда можно отнаследовать и переопределить метод, что и позволит подменять реализацию зависимости не меняя код зависимого. А ещё одна из основных целей DI — упрощение юнит-тестов достигается библиотекой моков, которая генерит наследников сама.
Код с DI можно писать с классами изначально, а если реально возникает потребность подставлять разные зависимости, то делается элементарный рефакторинг "extract interface", который тоже не затрагивает код зависимого. OCP и всё такое.

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

IT>>> Бизнес логика разбивается на части и разносится по разным частям приложения. Это затрудняет модификацию приложения.
.>>А можно пример? Каким образом тут DI приплетён? Если вдруг после того как зависимости стали делать управляемыми, ВНЕЗАПНО стало заметно, что у какого-то класса 50 зависимостей, 10000 строк кода и 0 юнит-тестов, то это не вина DI.
IT>При чём тут количество зависимосей, объём коди и юнит тесы?
А можно не игнорировать вопросы? Эти три вещи в большинстве случаев и затрудняют модификацию приложения, а не DI. А то получается "отравился печенюшкой".

IT>>>А всегда ли это нужно?
.>>Чаще чем не нужно, если ты пишешь что-то сложнее, чем фреймворк для умножения двух чисел

Автор: IT
Дата: 13.10.13

.
IT>Я уже устал от таких аргументов. Особенно когда под сложностью понимают не сложность задачи, а сложность собственной имплементации, которая в результате образовывается в том числе и из-за использования DI.
А я не понимаю таких примеров, больше на троллинг похоже.
Вопрос о том как управлять зависимостями, а ответ — перепишем код так, что зависимости где-то там, уличная магия какая-то.
Давай вот тут: http://code.google.com/p/google-guice/wiki/Motivation как ты переделаешь "по правильному, без DI"?

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

.>Давай вот тут: http://code.google.com/p/google-guice/wiki/Motivation как ты переделаешь "по правильному, без DI"?

Вот! Молодец! Более тупейшего применения DI я в жизни не видел (хотя такое же видел не раз). Как ты думаешь, что тестирует этот якобы "тест"? Я тебе отвечу. Он тестирует умение компилятора вызывать виртуальный метод. И больше НИЧЕГО. Вся бизнес логика, которую и нужно в конце концов тестировать тупо подменена фэйк-методами. Я фигею с вас, ребята