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

IQ>·>Я пока только вижу код, который назван "плохим". Но код не бывает абстрактно плохим. Он может быть только хуже/лучше некоего другого кода по неким критериям. Вот это я и пытаюсь выудить из тебя: какой код ты считаешь лучше и почему.
IQ> А незачем особенно всматриваться в код, код лишь намек по которому имхо очень просто определить антипаттерн.
IQ>Любой другой сходный г...код без DI будет лучше по одной простой причине — он будет значительно проще и меньше по объему в 2-3 раза. А значит не будет создавать препятствий рефакторингу
Блин. Пятый раз прошу! Покажи этот самый любой другой сходный гкод!!!

IQ>>> Нету в убогих проектах никаких юнит тестов не доживают они до них
IQ>·>Допустим. И причём тут DI?
IQ>При том, что его впихивают в проект обосновывая тем, что проще будет писать юнит тесты, которые, к слову как правило никогда не будут написаны
Ок. Да, пихают, но тесты не пишут. Тесты не пишут — да, это плохо, полностью согласен. А то что пихание само по себе плохо — мне не очевидно, обоснуй.

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

IQ>>>Расскажите это тем кто пытается пихать DI всюду где есть оператор new или вызов статической функции
IQ>·>Ага... значит интерфейсы тут не причём как выяснилось. Но в начальном сообщении new и статических функций не было. Может приведёшь более выразительный пример?
IQ>Для чего? Кейс мегатипичный, те кто сталкивался думаю сразу все поймут. А кто не сталкивался, увы, опыт придется получать самостоятельно.
Почему придётся? Может я никогда и не столкнусь.

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

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

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

IQ>>·>Я пока только вижу код, который назван "плохим". Но код не бывает абстрактно плохим. Он может быть только хуже/лучше некоего другого кода по неким критериям. Вот это я и пытаюсь выудить из тебя: какой код ты считаешь лучше и почему.
IQ>> А незачем особенно всматриваться в код, код лишь намек по которому имхо очень просто определить антипаттерн.
IQ>>Любой другой сходный г...код без DI будет лучше по одной простой причине — он будет значительно проще и меньше по объему в 2-3 раза. А значит не будет создавать препятствий рефакторингу
·>Блин. Пятый раз прошу! Покажи этот самый любой другой сходный гкод!!!

Как вы себе это представляете? Вам enterprise проект выложить? И вы в нем будете копаться? Я понимаю, что ваши требования явить конкретный пример это софистский прием, но не понимаю смысла, демонстрируемого вами упорства, в теме где нет холивара

IQ>>>> Нету в убогих проектах никаких юнит тестов не доживают они до них
IQ>>·>Допустим. И причём тут DI?
IQ>>При том, что его впихивают в проект обосновывая тем, что проще будет писать юнит тесты, которые, к слову как правило никогда не будут написаны
·>Ок. Да, пихают, но тесты не пишут. Тесты не пишут — да, это плохо, полностью согласен. А то что пихание само по себе плохо — мне не очевидно, обоснуй.

т.е. по вашему, принимать решения основываясь на причинах, которые причинами не являются, это серьезный разговор?

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

Это вы мне объясните каким волшебным образом решение о неуместном использовании DI попадает в ряд самых глупых и банальных ошибок

IQ>>·>Ага... значит интерфейсы тут не причём как выяснилось. Но в начальном сообщении new и статических функций не было. Может приведёшь более выразительный пример?
IQ>>Для чего? Кейс мегатипичный, те кто сталкивался думаю сразу все поймут. А кто не сталкивался, увы, опыт придется получать самостоятельно.
·>Почему придётся? Может я никогда и не столкнусь.

Значит незачем забивать себе голову

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

Проблема не в коде, а в ситуации. Если вы с такой не сталкивались, то вероятно пост не для вас.

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

IQ>·>Блин. Пятый раз прошу! Покажи этот самый любой другой сходный гкод!!!
IQ>Как вы себе это представляете? Вам enterprise проект выложить? И вы в нем будете копаться? Я понимаю, что ваши требования явить конкретный пример это софистский прием, но не понимаю смысла, демонстрируемого вами упорства, в теме где нет холивара
Нет, не приём. Просто не понимаю что в этом невозможного.

IQ>>>При том, что его впихивают в проект обосновывая тем, что проще будет писать юнит тесты, которые, к слову как правило никогда не будут написаны
IQ>·>Ок. Да, пихают, но тесты не пишут. Тесты не пишут — да, это плохо, полностью согласен. А то что пихание само по себе плохо — мне не очевидно, обоснуй.
IQ> т.е. по вашему, принимать решения основываясь на причинах, которые причинами не являются, это серьезный разговор?
Если напишут хоть пару тестов, уже хорошо. Таки объясни — чем пихание плохо?

IQ>>>·>Похоже ты обжёгся на молоке, и теперь дуешь на воду.
IQ>>>Я я пишу не о себе, а о других, которые почему-то массово делают одни и те же ошибки, увы связанные с DI. Потому пост и появился.
IQ>·>Ошибка — не писать тесты, ошибка — создавать интерфейс для каждого класса. Каким образом это связанно с DI?!
IQ>Это вы мне объясните каким волшебным образом решение о неуместном использовании DI попадает в ряд самых глупых и банальных ошибок
Опять двадцать пять. "неуместном использовании DI". Мой тезис — в типичном проекте неуместного использования DI не бывает, вещь хорошая сама по себе по сравнению альтернативами. Даже если не пишут тесты, но если таки решатся — будет проще начать. Даже если создают лишние интерфейсы — фигня какая, нажал кнопочку "refactor->inline" и готово.
Термин вон придумал — Colonoscopy Injection. А что в Constructor Injection плохого-то?

IQ>Проблема не в коде, а в ситуации. Если вы с такой не сталкивались, то вероятно пост не для вас.
Ладно, буду считать, что это некое эзотерическое знание, невыразимое в формате сообщения в форуме, только личный опыт позволяет постичь это.
Но мне не нравится, что говоря о чём попало, обвинения сыпятся в сторону ни в чём не повинного DI.

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

IQ>>>>·>Похоже ты обжёгся на молоке, и теперь дуешь на воду.
IQ>>>>Я я пишу не о себе, а о других, которые почему-то массово делают одни и те же ошибки, увы связанные с DI. Потому пост и появился.
IQ>>·>Ошибка — не писать тесты, ошибка — создавать интерфейс для каждого класса. Каким образом это связанно с DI?!
IQ>>Это вы мне объясните каким волшебным образом решение о неуместном использовании DI попадает в ряд самых глупых и банальных ошибок
·>Опять двадцать пять. "неуместном использовании DI". Мой тезис — в типичном проекте неуместного использования DI не бывает

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

Вам не в комментах стоит холиварить, а свой собственный пост запилить об абсолютной святости DI, с обоснованиями и доказательствами и приложенными enterprise проектами

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

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

0>>>Ты попробуй заставить идеи написать тебе программу без людей
IQ>> Гораздо интереснее то, что напишут люди без идей.
0>Я видел такое. Обычно это как-то работает, но внутри адский ад.
0>А когда экзальтированные юноши берутся делать "всё по уму", то оно не работает, а внутри адский ад.
0>Разница только в том, что под каждый элемент этого ада юноши могут сказать много умных слов, почему так сделано.
0>Между этими двумя вариантами я выбираю первый

Главная опасность второго варианта имхо в том, что имеющий оправдания, не станет ничего менять и исправлять.

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


IQ>Главная опасность второго варианта имхо в том, что имеющий оправдания, не станет ничего менять и исправлять.
Главная опасность в том, что продукт никогда не будет выпущен. Весь пар уйдёт в свисток архитектуру.

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

IQ>·>Опять двадцать пять. "неуместном использовании DI". Мой тезис — в типичном проекте неуместного использования DI не бывает
IQ>Вооот! Вот с этого и надо было начинать! А то объясни, докажи, покажи код А все это бессмысленно, если оппонент — религиозный фанатик упорствующий в ереси.
IQ>Вам не в комментах стоит холиварить, а свой собственный пост запилить об абсолютной святости DI,
Об абсолютной святости ты сам досочинил. Я утверждаю лишь что уж пусть будет гкод с DI, чем гкод без DI.

IQ>с обоснованиями и доказательствами
А собсвенно тут писать нечего. Если сделать работу за тебя и перечислить альтернативы DI:

1. big ball of mud
   
2. global variable
   
3. service locator

то станет очевидно, что DI не так уж плох как ты его рисуешь.

IQ>и приложенными enterprise проектами
Ага, ты значит запилил пост с какой-то лажей из пяти строк, а с меня enterprise проекты требуешь.

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

I>>Есть целая методология TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла, она популярная, модная, молодежная и все такое.
S>Она отлично работает для инфраструктуры, почти для любого масштаба, неплохо работает для мелочёвки и абсолютно не работает даже для средних проектов. Чтоб было понятно, что такое средний проект: представь себе типовой биз-кейз в виде 20-страничного документа 12 шрифтом, в котором 90% текста — не вода, а логика, причём высокоуровневая, без расписывания до отдельных инструкций.
Вот прекрасно всё работает, в условиях ещё более жёстких. Более того, без TDD всё очень плохо, так как про эту логику на 100500 листах 12-шрифтом через смену одного поколения разработчиков (2-3 года) никто знать даже не будет.

В случае TDD останутся тесты, которые хотя бы сломаются при "невинном" рефакторинге.

А если система ещё и сложная, с внешними зависимостями, то вообще вариантов никаких нет. Только TDD с mock'ами поведения внешних сервисов.

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

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

I>>>Есть целая методология TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла, она популярная, модная, молодежная и все такое.
S>>Она отлично работает для инфраструктуры, почти для любого масштаба, неплохо работает для мелочёвки и абсолютно не работает даже для средних проектов. Чтоб было понятно, что такое средний проект: представь себе типовой биз-кейз в виде 20-страничного документа 12 шрифтом, в котором 90% текста — не вода, а логика, причём высокоуровневая, без расписывания до отдельных инструкций.
C>Вот прекрасно всё работает, в условиях ещё более жёстких. Более того, без TDD всё очень плохо, так как про эту логику на 100500 листах 12-шрифтом через смену одного поколения разработчиков (2-3 года) никто знать даже не будет.

C>В случае TDD останутся тесты, которые хотя бы сломаются при "невинном" рефакторинге.

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

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

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

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

Для обоснования своей позиции я написал целый пост. Для обоснования своей вы не написали и одной полной строки. Несимметрично.

IQ>>с обоснованиями и доказательствами
·>А собсвенно тут писать нечего. Если сделать работу за тебя и перечислить альтернативы DI:
·>

·>
1. big ball of mud
   ·>
2. global variable
   ·>
3. service locator
   ·>

·>то станет очевидно, что DI не так уж плох как ты его рисуешь.

В последнее время, мне как раз попадались реализации big ball of mud исключительно с DI

global variable и service locator и что в них плохого на ранних этапах развития проекта? Вы забыли оператор new забанить, он же главный источник неуправляемых связей.

IQ>>и приложенными enterprise проектами
·>Ага, ты значит запилил пост с какой-то лажей из пяти строк, а с меня enterprise проекты требуешь.

Ну вы то пока даже с "лажей" поста не запилили, одно нытье и литании.

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

IQ>>>Вам не в комментах стоит холиварить, а свой собственный пост запилить об абсолютной святости DI,
IQ>·>Об абсолютной святости ты сам досочинил. Я утверждаю лишь что уж пусть будет гкод с DI, чем гкод без DI.
IQ> Для обоснования своей позиции я написал целый пост. Для обоснования своей вы не написали и одной полной строки. Несимметрично.
Я уже написал достаточно в этой ветке. Ты правда считаешь, что имеет смысл накопипастить новый пост?

IQ>В последнее время, мне как раз попадались реализации big ball of mud исключительно с DI
Так повезло, видимо, найди нормальную работу. Но с чего ты взял что BBoM с global variable или с service locator будет хоть чем-то лучше?

IQ>global variable и service locator и что в них плохого на ранних этапах развития проекта?
Тем что это типичный technical debt. Если, конечно, не писать проекты-однодневки (а с ними всё просто — пиши как хочешь, всё пофиг), то потом от них придётся избавляться, что всегда довольно болезненно: рефакторить DI проще, чем GV или SL.
Кстати, SL и реализовывать сложнее чем DI.

Кстати, вот это:

Лично для меня DI изначально был всего лишь удобным механизмом построения "плагинной архитектуры".

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

Далее:

Модули верхних уровней не должны зависеть от модулей нижних уровней

только именно так и получится сделать если использовать только DI с Constructor Injection. Ибо ты просто не сможешь создать объекты если уровни смешиваются. DAG, однако. В случае с GV и SL — легко получается месиво зависимостей всего от всего, которое потом фиг распутаешь.

IQ>Вы забыли оператор new забанить, он же главный источник неуправляемых связей.
Что значит забанить? В DI он не банится, а переносится наружу, в wiring-код.

IQ>>>и приложенными enterprise проектами
IQ>·>Ага, ты значит запилил пост с какой-то лажей из пяти строк, а с меня enterprise проекты требуешь.
IQ>Ну вы то пока даже с "лажей" поста не запилили, одно нытье и литании.
Да о чём тут пилить-то? Прочитай ту ссылку на вики с DI Examples, там всё вроде понятно.
Если нужен код, возьми свой и выкини интерфейсы:

public class HomeController : Controller

    public HomeController(
        BoringItemDataReader,
        BoringItemDataWriter,
        BoringItemChildDataReader,
        BoringItemChildDataWriter,
        AppDataJsonConverter,
    ...
)

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

·>Тем что это типичный technical debt. Если, конечно, не писать проекты-однодневки (а с ними всё просто — пиши как хочешь, всё пофиг), то потом от них придётся избавляться, что всегда довольно болезненно: рефакторить DI проще, чем GV или SL.

Ага! Наконец-то мне попался человек, который переделывает SL на DI, а не наоборот. Такой вопрос: а как вы решаете проблему цепочек зависимостей в бизнес-коде?
Ну, когда бизнес-сервис A вызывает B, тот — C и D и у всех есть свои уникальные зависимости?

·>А как ты реализуешь плагины с DI?
Как я понял, IQuerist про предоставление системного API плагинам, а не про встраивание самих плагинов. Для этого DI — самое оно, смотрим на extensions студии.

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


C>Вот прекрасно всё работает, в условиях ещё более жёстких.
Так мы не про сами тесты, а про "TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла".

Излишний радикализм с отдельными тестами на каждую мелочь на практике поднимает стоимость сопровождения раза в два из-за колоссального объёма кода, который приходится править при изменении бизнес-правил у очередного заказчика (что скорее обыденность, чем что-то исключительное). Комбинация "юнит-тесты где надо, интеграционные тесты для остального + ассерты везде" в этом плане намного дешевле.

C>А если система ещё и сложная, с внешними зависимостями, то вообще вариантов никаких нет. Только TDD с mock'ами поведения внешних сервисов.
Не-не-не, для сложных систем тру-TDD не работает. Получается ИБД в чистом виде. Везде красота и благолепие, тесты зеленеют, одни внедренцы без валерьянки к клиентам не ездят.

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

S>·>Тем что это типичный technical debt. Если, конечно, не писать проекты-однодневки (а с ними всё просто — пиши как хочешь, всё пофиг), то потом от них придётся избавляться, что всегда довольно болезненно: рефакторить DI проще, чем GV или SL.
S>Ага! Наконец-то мне попался человек, который переделывает SL на DI, а не наоборот. Такой вопрос: а как вы решаете проблему цепочек зависимостей в бизнес-коде?
S>Ну, когда бизнес-сервис A вызывает B, тот — C и D и у всех есть свои уникальные зависимости?
Не совсем понял. Что за проблема-то? Вроде пишешь как слышишь:

class ServiceA
{
    ServiceA(SerivceB b, CommonDependency1 cd1, CommonDependency2 cd2, UniqueDependecyA uA...)
}
class ServiceB
{
    ServiceB(SerivceC c, SerivceD d, CommonDependency1 cd1, CommonDependency2 cd2, UniqueDependecy1 u1...)
}
...

И что приятно — оно тебя будет круто бить по рукам, если вдруг захочется создать циклическую зависимость (захочешь вдруг использовать A из C — будет облом).

S>·>А как ты реализуешь плагины с DI?
S>Как я понял, IQuerist про предоставление системного API плагинам, а не про встраивание самих плагинов. Для этого DI — самое оно, смотрим на extensions студии.
Я Студию смотрел последний раз больше лет 10 назад... Можно подробнее? Что за extensions?

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

C>>Вот прекрасно всё работает, в условиях ещё более жёстких.
S>Так мы не про сами тесты, а про "TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла".
Пофиг. Юнит-тесты писать проще всего. И по наблюдениям, если юнит-тестов мало, то интеграционных тестов нет вообще.

S>Излишний радикализм с отдельными тестами на каждую мелочь на практике поднимает стоимость сопровождения раза в два из-за колоссального объёма кода, который приходится править при изменении бизнес-правил у очередного заказчика (что скорее обыденность, чем что-то исключительное).
Так это говнокод, однако. Если изменение одного заказчика ломает 100500 тестов, то код или тесты написаны плохо. Думайте как переделать.

C>>А если система ещё и сложная, с внешними зависимостями, то вообще вариантов никаких нет. Только TDD с mock'ами поведения внешних сервисов.
S>Не-не-не, для сложных систем тру-TDD не работает. Получается ИБД в чистом виде. Везде красота и благолепие, тесты зеленеют, одни внедренцы без валерьянки к клиентам не ездят.
Тесты значительно СНИЖАЮТ стоимость разработки как раз из-за этого. Программист после небольшого изменения не ждёт конца интеграционных тестов, а сразу запускает локальные юнит-тесты с mock'ами. Конечно, они не идеальны, но находят процентов так 95 рутинных ошибок времени разработки.

Вторые 95% догоняются на этапе интеграционного тестирования.

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

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

IQ>>>>Вам не в комментах стоит холиварить, а свой собственный пост запилить об абсолютной святости DI,
IQ>>·>Об абсолютной святости ты сам досочинил. Я утверждаю лишь что уж пусть будет гкод с DI, чем гкод без DI.
IQ>> Для обоснования своей позиции я написал целый пост. Для обоснования своей вы не написали и одной полной строки. Несимметрично.
·>Я уже написал достаточно в этой ветке. Ты правда считаешь, что имеет смысл накопипастить новый пост?

Вам решать

IQ>>В последнее время, мне как раз попадались реализации big ball of mud исключительно с DI
·>Так повезло, видимо, найди нормальную работу. Но с чего ты взял что BBoM с global variable или с service locator будет хоть чем-то лучше?

Бесполезно кругом одни и те же сектанты DI.

IQ>>global variable и service locator и что в них плохого на ранних этапах развития проекта?
·>Тем что это типичный technical debt.

На ранних этапах имхо "technical debt" и "оптимизация" не те вещи от которых что-то зависит.

>>>Если, конечно, не писать проекты-однодневки (а с ними всё просто — пиши как хочешь, всё пофиг), то потом от них придётся избавляться, что всегда довольно болезненно: рефакторить DI проще, чем GV или SL.

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

·>Кстати, вот это:
·>

Лично для меня DI изначально был всего лишь удобным механизмом построения "плагинной архитектуры".

·>тоже не понимание предмета. Вот как раз SL лучше подходит для плагинной архитектуры, особенно когда связывание происходит runtime.
·>А как ты реализуешь плагины с DI?

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

·>Далее:
·>

Модули верхних уровней не должны зависеть от модулей нижних уровней

·>только именно так и получится сделать если использовать только DI с Constructor Injection. Ибо ты просто не сможешь создать объекты если уровни смешиваются. DAG, однако.

Нда... 98% виденных мною внедряемых сервисов были DAL хелперами. Ну и как же без обязательного для такого случая ILoggerManager. Обращаю в 1001 раз ваше внимание DAL это крайне низкий уровень. И никакие обертки и мапперы не делают его выше.

·>В случае с GV и SL — легко получается месиво зависимостей всего от всего, которое потом фиг распутаешь.

Я собственно и написал, пост из за того, что с использованием DI делает такое месиво куда более "густым"

IQ>>Вы забыли оператор new забанить, он же главный источник неуправляемых связей.
·>Что значит забанить? В DI он не банится, а переносится наружу, в wiring-код.

Забанить значит — тотально (по религиозным причинам)

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

C>>>А если система ещё и сложная, с внешними зависимостями, то вообще вариантов никаких нет. Только TDD с mock'ами поведения внешних сервисов.
S>>Не-не-не, для сложных систем тру-TDD не работает. Получается ИБД в чистом виде. Везде красота и благолепие, тесты зеленеют, одни внедренцы без валерьянки к клиентам не ездят.
C>Тесты значительно СНИЖАЮТ стоимость разработки как раз из-за этого. Программист после небольшого изменения не ждёт конца интеграционных тестов, а сразу запускает локальные юнит-тесты с mock'ами. Конечно, они не идеальны, но находят процентов так 95 рутинных ошибок времени разработки.

Какие-то вы фантастические вещи рассказываете. Вы в какой области работаете?

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

S>>·>А как ты реализуешь плагины с DI?
S>>Как я понял, IQuerist про предоставление системного API плагинам, а не про встраивание самих плагинов. Для этого DI — самое оно, смотрим на extensions студии.
·>Я Студию смотрел последний раз больше лет 10 назад... Можно подробнее? Что за extensions?

А вот это уже интересно в какой же программерской области находится подлинное царство DI? В какой области вы работаете и на чем?

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

C>>Тесты значительно СНИЖАЮТ стоимость разработки как раз из-за этого. Программист после небольшого изменения не ждёт конца интеграционных тестов, а сразу запускает локальные юнит-тесты с mock'ами. Конечно, они не идеальны, но находят процентов так 95 рутинных ошибок времени разработки.
IQ>Какие-то вы фантастические вещи рассказываете. Вы в какой области работаете?
Я внутри Amazon'а работаю в облачных вычислениях. Самый эпицентр service-based архитектуры, можно сказать. Языки разработки — Java и производные от неё.

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

IQ>>>В последнее время, мне как раз попадались реализации big ball of mud исключительно с DI
IQ>·>Так повезло, видимо, найди нормальную работу. Но с чего ты взял что BBoM с global variable или с service locator будет хоть чем-то лучше?
IQ>Бесполезно кругом одни и те же сектанты DI.
"Да их тут тысячи!" (c)

IQ>>>global variable и service locator и что в них плохого на ранних этапах развития проекта?
IQ>·>Тем что это типичный technical debt.
IQ> На ранних этапах имхо "technical debt" и "оптимизация" не те вещи от которых что-то зависит.
А гкодерство и пессимизация — от них зависит перспективность проекта.

>>>>Если, конечно, не писать проекты-однодневки (а с ними всё просто — пиши как хочешь, всё пофиг), то потом от них придётся избавляться, что всегда довольно болезненно: рефакторить DI проще, чем GV или SL.
IQ>Ну сказочки то не рассказывайте. DI дает очень серьезную синтаксическую нагрузку,
Какую нагрузку? Появляется только конструктор со списком зависимостей. Всё.
Кстати, это хороший индикатор. Если этот самый конструктор начинает выглядеть монструозно, то это значит что класс начинает становиться универсальным всемогутером, нужен рефакторинг.

IQ>плюс как правило неумелый дизайн модели с постоянным копированием и мапингом одних и тех же entity. Из за этого часто вообще не хочется затевать рефакторинг.
Блин... Ещё какие-то маппинги вылезли. И причём тут DI??

IQ>·>Кстати, вот это:
IQ>·>

Лично для меня DI изначально был всего лишь удобным механизмом построения "плагинной архитектуры".

IQ>·>тоже не понимание предмета. Вот как раз SL лучше подходит для плагинной архитектуры, особенно когда связывание происходит runtime.
IQ>·>А как ты реализуешь плагины с DI?
IQ>Никак мои проекты это тонны быстро устаревающей бизнес логики, которую заказчик хочет получить как правило вчера. Никаких плагинов там не вырисовывается в принципе, код завязан на конкретную бизнес логику никакой реюз не предполагается. Спасает исключительно дисциплина и декомпозиция.
DI к реюзу тоже не относится (или ты опять про интерфейсы?!), а вот дисциплину и декомпозицию он улучшает, засчёт того, что явно требует структурировать зависимости в DAG.

IQ>·>Далее:
IQ>·>

Модули верхних уровней не должны зависеть от модулей нижних уровней

IQ>·>только именно так и получится сделать если использовать только DI с Constructor Injection. Ибо ты просто не сможешь создать объекты если уровни смешиваются. DAG, однако.
IQ>Нда... 98% виденных мною внедряемых сервисов были DAL хелперами. Ну и как же без обязательного для такого случая ILoggerManager. Обращаю в 1001 раз ваше внимание DAL это крайне низкий уровень. И никакие обертки и мапперы не делают его выше.
Уже хорошо. Хуже когда из DAL-хелперов кто-то вдруг начинает обращаться к HttpContext.Current.

IQ>·>В случае с GV и SL — легко получается месиво зависимостей всего от всего, которое потом фиг распутаешь.
IQ> Я собственно и написал, пост из за того, что с использованием DI делает такое месиво куда более "густым"
Каким образом? Оно же тупо не скомпилится.

IQ>>>Вы забыли оператор new забанить, он же главный источник неуправляемых связей.
IQ>·>Что значит забанить? В DI он не банится, а переносится наружу, в wiring-код.
IQ>Забанить значит — тотально (по религиозным причинам)
Ну бань, если хочется. Но причём тут DI???