Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например как альтернатива serivce locator. В более общем виде — dynamic scoping.
SL — это тот же DI, только хуже. В DI хоть зависимости в контракте видно, в отличии от..
— в одном из мест противопоставление, в другом наоборот подтип.
IB>только хуже.
Нельзя сказать определённо хуже или лучше, так как есть случаи где выгодней применять одно, а есть — где выгодней другое. А значит где-то хуже одно, а где-то другое
IB>В DI хоть зависимости в контракте видно, в отличии от..
Да, это одно из преимуществ, но не делает автоматически "лучше".
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, IQuerist, Вы писали:
IQ>>О "наивном" DI и об архитектурном бессилии 0>При чем тут DI?
0>Проблема в экзальтированных юношах (любого возраста), которые из-за максимализма и неопытности "следуют принципам" вместо того чтобы думать. 0>В их руках абсолютно что угодно станет оружием судного дня для проекта.
Может comrade... я написал про DI, вы можете написать про все остальное — "что угодно"...
Кстати любопытная ситуация, остальное "что угодно" не больно то потакает сокрытию архитектурных проблем , а вот у DI это получается просто блестяще... Приделай к самой низкопробной дряни интерфейс, заверни в DI контейнер и ты мега архитект!
Здравствуйте, IQuerist, Вы писали:
IQ>Кстати любопытная ситуация, остальное "что угодно" не больно то потакает сокрытию архитектурных проблем , а вот у DI это получается просто блестяще... Приделай к самой низкопробной дряни интерфейс, заверни в DI контейнер и ты мега архитект!
DI сам по себе отличная штука. Однако когда доходит до деталей, а ещё не все понимают разницу...
Вот скажем "DI" и "DI IoC-контейнер" это разные вещи. Использовать DI можно (а на прошлой моей работе даже решили что нужно) без контейнера.
И интерфейсы тоже к DI отношения не имеют. Можно использовать DI и без интерфейсов.
Так что... сабж?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IQuerist, Вы писали:
0>>В их руках абсолютно что угодно станет оружием судного дня для проекта. IQ>Может comrade... я написал про DI, вы можете написать про все остальное — "что угодно"...
Ну, я видел победу модульности над здравым смыслом. Победу паттернов над здравым смыслом (особенно лютовал Visitor).
Победу микросервисов над здравым смыслом. Победу message queue над здравым смыслом. Победу DDD на здравым смыслом.
Ну и прочие триумфы сил добра над силами разума DI тут ничем особенно не выделяется.
IQ>Кстати любопытная ситуация, остальное "что угодно" не больно то потакает сокрытию архитектурных проблем , а вот у DI это получается просто блестяще... Приделай к самой низкопробной дряни интерфейс, заверни в DI контейнер и ты мега архитект!
Ой, да ладно. Они все скрывают одни архитектурные проблемы, создавая другие проблемы на ровном месте
Хотя, конечно, это не "они" (сиречь, паттерны) а люди. Вся проблема в людях и только в них.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>Кстати любопытная ситуация, остальное "что угодно" не больно то потакает сокрытию архитектурных проблем , а вот у DI это получается просто блестяще... Приделай к самой низкопробной дряни интерфейс, заверни в DI контейнер и ты мега архитект!
·>DI сам по себе отличная штука.
А этим никто не спорит. Проблема в том, что им уж очень часто пытаются подменить архитектуру.
·>Вот скажем "DI" и "DI IoC-контейнер" это разные вещи. Использовать DI можно (а на прошлой моей работе даже решили что нужно) без контейнера. ·>И интерфейсы тоже к DI отношения не имеют. Можно использовать DI и без интерфейсов.
Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу.
Здравствуйте, 0x7be, Вы писали:
0>Хотя, конечно, это не "они" (сиречь, паттерны) а люди. Вся проблема в людях и только в них.
Ну уж ладно наша отрасль имхо построена таки не на людях, а на идеях. А идеи принадлежат сообществам. Так что причина должна быть в каких-то сообществах которые распространяют неполные идеи
Здравствуйте, IQuerist, Вы писали:
IQ>Ну уж ладно наша отрасль имхо построена таки не на людях, а на идеях. А идеи принадлежат сообществам. Так что причина должна быть в каких-то сообществах которые распространяют неполные идеи ))
Ты попробуй заставить идеи написать тебе программу без людей
Или возьми случайных людей с улицы, дай им книжку с правильными идеями и посмотри, что они тебе сделают
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, IQuerist, Вы писали:
IQ>>Ну уж ладно наша отрасль имхо построена таки не на людях, а на идеях. А идеи принадлежат сообществам. Так что причина должна быть в каких-то сообществах которые распространяют неполные идеи )) 0>Ты попробуй заставить идеи написать тебе программу без людей
Гораздо интереснее то, что напишут люди без идей.
0>Или возьми случайных людей с улицы, дай им книжку с правильными идеями и посмотри, что они тебе сделают
Неверно идеи принадлежат сообществам. Идеи изложенные в книгах это таки опять частное изложение частного видения...
Здравствуйте, IQuerist, Вы писали:
0>>Ты попробуй заставить идеи написать тебе программу без людей IQ> Гораздо интереснее то, что напишут люди без идей.
Я видел такое. Обычно это как-то работает, но внутри адский ад.
А когда экзальтированные юноши берутся делать "всё по уму", то оно не работает, а внутри адский ад.
Разница только в том, что под каждый элемент этого ада юноши могут сказать много умных слов, почему так сделано.
Между этими двумя вариантами я выбираю первый
0>>Или возьми случайных людей с улицы, дай им книжку с правильными идеями и посмотри, что они тебе сделают IQ>Неверно идеи принадлежат сообществам. Идеи изложенные в книгах это таки опять частное изложение частного видения...
Что не верно?
Сделай какое-нибудь утверждение, а то спор зашёл в тупик
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, IQuerist, Вы писали:
0>>>Ты попробуй заставить идеи написать тебе программу без людей IQ>> Гораздо интереснее то, что напишут люди без идей. 0>Между этими двумя вариантами я выбираю первый
Я кстати тоже Какой смысл делать инвестиции в заведомый г...код.
0>>>Или возьми случайных людей с улицы, дай им книжку с правильными идеями и посмотри, что они тебе сделают IQ>>Неверно идеи принадлежат сообществам. Идеи изложенные в книгах это таки опять частное изложение частного видения... 0>Что не верно? 0>Сделай какое-нибудь утверждение, а то спор зашёл в тупик
Да, over-philosophy детектед это наводки из другого хреда
Здравствуйте, IQuerist, Вы писали:
IQ>Я кстати тоже Какой смысл делать инвестиции в заведомый г...код.
Очень простой. Если ты знаешь, что этот г-код тебе принесет деньги, то почему бы и нет?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, IQuerist, Вы писали:
IQ>>Я кстати тоже Какой смысл делать инвестиции в заведомый г...код.
0>Очень простой. Если ты знаешь, что этот г-код тебе принесет деньги, то почему бы и нет?
Не... я про то, что не стоит тратить время и силы пытаясь представить г...код в виде что-то пристойного.
Какой смысл делать ЛИШНИЕ инвестиции в заведомый г...код.
Здравствуйте, IQuerist, Вы писали:
IQ>·>Вот скажем "DI" и "DI IoC-контейнер" это разные вещи. Использовать DI можно (а на прошлой моей работе даже решили что нужно) без контейнера. IQ>·>И интерфейсы тоже к DI отношения не имеют. Можно использовать DI и без интерфейсов. IQ>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу.
Ты описал кейс, но не предложил альтернативу. Как надо-то по-твоему?
IQ>Гиперболизируя можно было бы добавить еще IJsonConverter чтобы механизм конвертирования json можно было изменить
А ты не подумал, что тот же JsonConverter может иметь ещё пять зависимостей, скажем настройки форматирования json и какие-нибудь там сериализаторы кастомных типов?
IQ>и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но
А мы так сделали в нашем проекте, ибо да, у нас "текущее время" оказалось вещью необычной.
IQ>на всякий случай стоит "уменьшить зависимости"
DI не уменьшает зависимости, а делает их явными.
Единственное что в твоём коде я бы поменял, так это выкинул все эти I* интерфейсы и инжектил бы сами классы. Интерфейс лежащий рядом с единственной имплементацией — не нужен.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, IQuerist, Вы писали:
IQ>Не... я про то, что не стоит тратить время и силы пытаясь представить г...код в виде что-то пристойного. IQ>Какой смысл делать ЛИШНИЕ инвестиции в заведомый г...код.
Теперь понял
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу. ·>Ты описал кейс, но не предложил альтернативу. Как надо-то по-твоему?
Альтернатива простая — г...кодить г...код без DI.
IQ>>Гиперболизируя можно было бы добавить еще IJsonConverter чтобы механизм конвертирования json можно было изменить ·>А ты не подумал, что тот же JsonConverter может иметь ещё пять зависимостей, скажем настройки форматирования json и какие-нибудь там сериализаторы кастомных типов? IQ>>и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но ·>А мы так сделали в нашем проекте, ибо да, у нас "текущее время" оказалось вещью необычной.
Я привел имхо довольно понятную ситуацию, зачем вы мне описываете варианты где использование DI вполне уместно? Я же не говорю, что таких вообще не существует.
IQ>>на всякий случай стоит "уменьшить зависимости" ·>DI не уменьшает зависимости, а делает их явными.
Мы используем DI чтобы уменьшить/снизить зависимости — это не моя формулировка, это первое из обоснований наивного использования DI. Второе — DI позволит нам еще лучше писать юнит тесты.
·>Единственное что в твоём коде я бы поменял, так это выкинул все эти I* интерфейсы и инжектил бы сами классы. Интерфейс лежащий рядом с единственной имплементацией — не нужен.
Тогда пропадает видимость IoC — половина священной коровы.
Здравствуйте, IQuerist, Вы писали:
IQ>>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу. IQ>·>Ты описал кейс, но не предложил альтернативу. Как надо-то по-твоему? IQ>Альтернатива простая — г...кодить г...код без DI.
Это как? И чем это лучше?
IQ>>>и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но IQ>·>А мы так сделали в нашем проекте, ибо да, у нас "текущее время" оказалось вещью необычной. IQ>Я привел имхо довольно понятную ситуацию, зачем вы мне описываете варианты где использование DI вполне уместно? Я же не говорю, что таких вообще не существует.
Ты привёл ситуацию, но я не вижу в ней ничего криминального. Я и пытаюсь добиться конкретики. Что именно плохо и как должно быть чтобы стало хорошо?
IQ>>>на всякий случай стоит "уменьшить зависимости" IQ>·>DI не уменьшает зависимости, а делает их явными. IQ>Мы используем DI чтобы уменьшить/снизить зависимости — это не моя формулировка, это первое из обоснований наивного использования DI. Второе — DI позволит нам еще лучше писать юнит тесты.
Это уже следствие. Когда зависимости явные — их можно перелопатить и уменьшить.
ЮТ — да, как следствие тоже упрощаются, т.к. понятие юнита тоже становится явным.
IQ>·>Единственное что в твоём коде я бы поменял, так это выкинул все эти I* интерфейсы и инжектил бы сами классы. Интерфейс лежащий рядом с единственной имплементацией — не нужен. IQ> Тогда пропадает видимость — IoC половина священной коровы.
Ы? Что за бред? Что пропадает? Куда пропадает?
В DI никаких интерфейсов нет. Найди мне их тут: https://en.wikipedia.org/wiki/Dependency_injection#Examples
Видимо просто люди не понимают что такое DI, но свои проблемы валят именно на него.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу. IQ>>·>Ты описал кейс, но не предложил альтернативу. Как надо-то по-твоему? IQ>>Альтернатива простая — г...кодить г...код без DI. ·>Это как? И чем это лучше?
это значительно экономит время и силы и г...кодеру и окружающим...
IQ>>>>и что ни будь вроде IDateTimeProvider, работа с датой и временем вряд ли поменяется, но IQ>>·>А мы так сделали в нашем проекте, ибо да, у нас "текущее время" оказалось вещью необычной. IQ>>Я привел имхо довольно понятную ситуацию, зачем вы мне описываете варианты где использование DI вполне уместно? Я же не говорю, что таких вообще не существует. ·>Ты привёл ситуацию, но я не вижу в ней ничего криминального. Я и пытаюсь добиться конкретики. Что именно плохо и как должно быть чтобы стало хорошо?
То ли боги тотально берегли вас от случаев убогого использования DI, то ли вы видели его на на картинках в книжках... Если вы не видите в моем примере типичного антипаттерна, я могу вам только позавидовать.
IQ>>>>на всякий случай стоит "уменьшить зависимости" IQ>>·>DI не уменьшает зависимости, а делает их явными. IQ>>Мы используем DI чтобы уменьшить/снизить зависимости — это не моя формулировка, это первое из обоснований наивного использования DI. Второе — DI позволит нам еще лучше писать юнит тесты. ·>Это уже следствие. Когда зависимости явные — их можно перелопатить и уменьшить. ·>ЮТ — да, как следствие тоже упрощаются, т.к. понятие юнита тоже становится явным.
Нету в убогих проектах никаких юнит тестов не доживают они до них
IQ>>·>Единственное что в твоём коде я бы поменял, так это выкинул все эти I* интерфейсы и инжектил бы сами классы. Интерфейс лежащий рядом с единственной имплементацией — не нужен. IQ>> Тогда пропадает видимость — IoC половина священной коровы. ·>Ы? Что за бред? Что пропадает? Куда пропадает? ·>В DI никаких интерфейсов нет. Найди мне их тут: https://en.wikipedia.org/wiki/Dependency_injection#Examples
Расскажите это тем кто пытается пихать DI всюду где есть оператор new или вызов статической функции
Здравствуйте, IQuerist, Вы писали:
IQ>>>Альтернатива простая — г...кодить г...код без DI. IQ>·>Это как? И чем это лучше? IQ> это значительно экономит время и силы и г...кодеру и окружающим...
Так покажи этот код без DI. Ты показал "плохой" код, теперь давай "хороший" код в студию.
IQ>·>Ты привёл ситуацию, но я не вижу в ней ничего криминального. Я и пытаюсь добиться конкретики. Что именно плохо и как должно быть чтобы стало хорошо? IQ>То ли боги тотально берегли вас от случаев убогого использования DI, то ли вы видели его на на картинках в книжках... Если вы не видите в моем примере типичного антипаттерна, я могу вам только позавидовать.
Я пока только вижу код, который назван "плохим". Но код не бывает абстрактно плохим. Он может быть только хуже/лучше некоего другого кода по неким критериям. Вот это я и пытаюсь выудить из тебя: какой код ты считаешь лучше и почему.
IQ> Нету в убогих проектах никаких юнит тестов не доживают они до них
Допустим. И причём тут DI?
Похоже ты обжёгся на молоке, и теперь дуешь на воду.
IQ>>> Тогда пропадает видимость — IoC половина священной коровы. IQ>·>Ы? Что за бред? Что пропадает? Куда пропадает? IQ>·>В DI никаких интерфейсов нет. Найди мне их тут: https://en.wikipedia.org/wiki/Dependency_injection#Examples IQ>Расскажите это тем кто пытается пихать DI всюду где есть оператор new или вызов статической функции
Ага... значит интерфейсы тут не причём как выяснилось. Но в начальном сообщении new и статических функций не было. Может приведёшь более выразительный пример?
Т.е. проблема в том, что люди создают интерфейсы где попало, бормоча "во имя DI!", так что-ли? Ну такое надо лечить только ликбезом по мягким местам...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, IQuerist, Вы писали:
IQ>>·>Ты привёл ситуацию, но я не вижу в ней ничего криминального. Я и пытаюсь добиться конкретики. Что именно плохо и как должно быть чтобы стало хорошо? IQ>>То ли боги тотально берегли вас от случаев убогого использования DI, то ли вы видели его на на картинках в книжках... Если вы не видите в моем примере типичного антипаттерна, я могу вам только позавидовать. ·>Я пока только вижу код, который назван "плохим". Но код не бывает абстрактно плохим. Он может быть только хуже/лучше некоего другого кода по неким критериям. Вот это я и пытаюсь выудить из тебя: какой код ты считаешь лучше и почему.
А незачем особенно всматриваться в код, код лишь намек по которому имхо очень просто определить антипаттерн.
Любой другой сходный г...код без DI будет лучше по одной простой причине — он будет значительно проще и меньше по объему в 2-3 раза. А значит не будет создавать препятствий рефакторингу
IQ>> Нету в убогих проектах никаких юнит тестов не доживают они до них ·>Допустим. И причём тут DI?
При том, что его впихивают в проект обосновывая тем, что проще будет писать юнит тесты, которые, к слову как правило никогда не будут написаны
·>Похоже ты обжёгся на молоке, и теперь дуешь на воду.
Я я пишу не о себе, а о других, которые почему-то массово делают одни и те же ошибки, увы связанные с DI. Потому пост и появился.
IQ>>>> Тогда пропадает видимость — IoC половина священной коровы. IQ>>·>Ы? Что за бред? Что пропадает? Куда пропадает? IQ>>·>В DI никаких интерфейсов нет. Найди мне их тут: https://en.wikipedia.org/wiki/Dependency_injection#Examples IQ>>Расскажите это тем кто пытается пихать DI всюду где есть оператор new или вызов статической функции ·>Ага... значит интерфейсы тут не причём как выяснилось. Но в начальном сообщении new и статических функций не было. Может приведёшь более выразительный пример?
Для чего? Кейс мегатипичный, те кто сталкивался думаю сразу все поймут. А кто не сталкивался, увы, опыт придется получать самостоятельно.
·>Т.е. проблема в том, что люди создают интерфейсы где попало, бормоча "во имя DI!", так что-ли? Ну такое надо лечить только ликбезом по мягким местам...
Так и я о том же. Но я выделил имхо общепринятый антипаттерн, о котором и написал пост. Пост ведь называется не "Какой же б-гомерзкий этот ваш DI, гореть ему в аду", а — "О "наивном" DI и об архитектурном бессилии".
Мы уже победили, просто это еще не так заметно...
, а вот у DI это получается просто блестяще... Приделай к самой низкопробной дряни интерфейс, заверни в DI контейнер и ты мега архитект!
Гораздо интереснее то, что напишут люди без идей. 
это значительно экономит время и силы и г...кодеру и окружающим...