Сообщение Re[8]: При чем тут Di? от 11.08.2016 15:23
Изменено 11.08.2016 15:24 IQuerist
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 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>>>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу.
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 или вызов статической функции
Re[8]: При чем тут 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>>>>Можно делать всякое... я описал конкретный кейс который имхо наблюдается повсеместно, но почему-то мало критикуется или критикуется не по делу.
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 или вызов статической функции