Re[2]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 29.07.16 12:54
Оценка: :)
Здравствуйте, _hum_, Вы писали:

__>так все-таки, какая основная мысль вашего поста — что бездумное использование DI — типичная ошибка неумелого архитектора, или, что сам паттерн переоценен?


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

И как справедливо написали в камментах:

>>>В случае с невменяемым DI получается, что конфигурация заменяет архитектуру.
Re[3]: О "наивном" DI и об архитектурном бессилии
От: _hum_ Беларусь  
Дата: 29.07.16 14:08
Оценка:
Здравствуйте, IQuerist, Вы писали:

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


__>>так все-таки, какая основная мысль вашего поста — что бездумное использование DI — типичная ошибка неумелого архитектора, или, что сам паттерн переоценен?


IQ>Думаю общая проблема в другом. DI стимулирует неопытных разработчиков городить непродуманные и хрупкие абстракции на ранних стадиях проекта причем там где их нет и быть не может (т.к. в первую очередь они создают DAL), нарушая принципы SOLID. Эти хрупкие абстракции начнут сильно мешать при построении бизнес логики, когда сил и энтузиазма будет уже не так много. А когда еще и сроки начнут поджимать, то бизнес логика оказывается в самом плачевном состоянии.


IQ>И как справедливо написали в камментах:


>>>>В случае с невменяемым DI получается, что конфигурация заменяет архитектуру.



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

кстати, в той же wiki указаны недосатки (наряду с достоинствами), в том числе и те, о которых вы говорите: Dependency_injection_frameworks
Re[4]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 29.07.16 14:40
Оценка:
Здравствуйте, _hum_, Вы писали:

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


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

__>кстати, в той же wiki указаны недосатки (наряду с достоинствами), в том числе и те, о которых вы говорите: Dependency_injection_frameworks


Имхо главного не написано — маниакальная страсть к IOC навязываемая ранним внедрением DI провоцирует нарушение всех принципов SOLID.
Re[5]: О "наивном" DI и об архитектурном бессилии
От: _hum_ Беларусь  
Дата: 29.07.16 14:58
Оценка:
Здравствуйте, IQuerist, Вы писали:

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


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


IQ>Думаю да, инструменты и механизмы надо использовать по мере необходимости, а не потому, что так модно.


так это верно для любого случая. почему вы выделили именно DI?

__>>кстати, в той же wiki указаны недосатки (наряду с достоинствами), в том числе и те, о которых вы говорите: Dependency_injection_frameworks


IQ>Имхо главного не написано — маниакальная страсть к IOC навязываемая ранним внедрением DI провоцирует нарушение всех принципов SOLID.


на что все-таки логическое ударение — на "маниакальная страсть к IOC" или на "ранее внедрение DI"?
Re[3]: О "наивном" DI и об архитектурном бессилии
От: Sinix  
Дата: 29.07.16 15:03
Оценка: 8 (1) +5
Здравствуйте, Lexey, Вы писали:

L>А как ты предлагаешь подсовывать моки/фейки без DI?

В самых тяжёлых случаях — moq/ms fakes/NSubstitute etc. Во всех остальных проще и дешевле использовать интеграционные тесты. Те же юнит-тесты, только вся инфраструктура уже заведена и доступна к использованию.

Оно хоть и немного гемморойней на начальном этапе, но зато в итоге не будет такого, что тесты зелёные, а вот работать — упс.


L>Что такое "родная ниша" DI?


Я ж выше писал Большие проекты с необходимостью поддерживать плагины от сторонних разработчиков. Вот там DI творит чудеса. Самый простой пример — расширения студии. Сравни число расширений для кода, который подрубается через MEF (редактор по сути) и то, для чего нормальное API только в процессе (lang services, debugging api etc).
Re[4]: О "наивном" DI и об архитектурном бессилии
От: Lexey Россия  
Дата: 29.07.16 17:44
Оценка: 7 (2) +6
Здравствуйте, Sinix, Вы писали:

S>В самых тяжёлых случаях — moq/ms fakes/NSubstitute etc. Во всех остальных проще и дешевле использовать интеграционные тесты. Те же юнит-тесты, только вся инфраструктура уже заведена и доступна к использованию.


Может у тебя специфика такая. У меня, как правило, ситуация обратная. Юнит-тесты писать проще и дешевле, чем интеграционные. И исполняются они на порядки быстрее. А бывало и так, что хороший интеграционный тест в принципе невозможен. И самое интересное вылезает в процессе пуско-наладки.

S>Оно хоть и немного гемморойней на начальном этапе, но зато в итоге не будет такого, что тесты зелёные, а вот работать — упс.


В идеале хорошо и то и то иметь зеленым.

S>Я ж выше писал Большие проекты с необходимостью поддерживать плагины от сторонних разработчиков. Вот там DI творит чудеса. Самый простой пример — расширения студии. Сравни число расширений для кода, который подрубается через MEF (редактор по сути) и то, для чего нормальное API только в процессе (lang services, debugging api etc).


ИМХО, DI-контейнеры — это все-таки весьма частный случай DI, а не его родная ниша. Простейший DI (в виде передачи функции или объекта в другую) существовал задолго до того, как начали массово лепить контейнеры везде, где только можно (и чаще всего не нужно). Только никто его так не называл.
"Будь достоин победы" (c) 8th Wizard's rule.
Re[5]: О "наивном" DI и об архитектурном бессилии
От: Evgeny.Panasyuk Россия  
Дата: 29.07.16 18:01
Оценка: +1
Здравствуйте, Lexey, Вы писали:

L>ИМХО, DI-контейнеры — это все-таки весьма частный случай DI, а не его родная ниша. Простейший DI (в виде передачи функции или объекта в другую) существовал задолго до того, как начали массово лепить контейнеры везде, где только можно (и чаще всего не нужно). Только никто его так не называл.


+1
Видимо "параметр" звучит недостаточно солидно и паттерново
Re[5]: О "наивном" DI и об архитектурном бессилии
От: Vladek Россия Github
Дата: 29.07.16 21:16
Оценка: +1
Здравствуйте, Lexey, Вы писали:

L>ИМХО, DI-контейнеры — это все-таки весьма частный случай DI, а не его родная ниша. Простейший DI (в виде передачи функции или объекта в другую) существовал задолго до того, как начали массово лепить контейнеры везде, где только можно (и чаще всего не нужно). Только никто его так не называл.


Обобщающий термин — инверсия управления.

https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F
Re[4]: О "наивном" DI и об архитектурном бессилии
От: itslave СССР  
Дата: 30.07.16 11:27
Оценка:
Здравствуйте, Sinix, Вы писали:

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


L>>А как ты предлагаешь подсовывать моки/фейки без DI?

S>В самых тяжёлых случаях — moq/ms fakes/NSubstitute etc.
Дык вот если не будет DI, то моки из вышеперечисленных либ по простому прокинуть в тестируемый класс не получится.

S>Во всех остальных проще и дешевле использовать интеграционные тесты. Те же юнит-тесты, только вся инфраструктура уже заведена и доступна к использованию.

Не проще и не дешевле. И писать тяжелей среднестатистическому деву(автоматизаторы вообще отдельная профессия), и дебажить(ну там к примеру рандомные тормоза http, которые локально не репродьясятся валят тесты на серваке), и ранаются они гораздо дольше. А если есть много интеграций с третьесторонними сервисами, то все становится

S>Оно хоть и немного гемморойней на начальном этапе, но зато в итоге не будет такого, что тесты зелёные, а вот работать — упс.

Поэтому нужны и те и эти тесты: юнит чтобы локально прогнать и убедиться что "бизнес логику не поломал" и интеграционные чтобы убедиться в работоспособности приложения.
Re[5]: О "наивном" DI и об архитектурном бессилии
От: Sinix  
Дата: 30.07.16 14:08
Оценка:
Здравствуйте, itslave, Вы писали:

S>>В самых тяжёлых случаях — moq/ms fakes/NSubstitute etc.

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

Тут полтопика путает DI с IoC, так что вы в хорошей компании

Сорри за подколку. Если серьёзно, то оформление инфраструктурного API в виде интерфейсов и DI — вещи ортогональные. К первому рано или поздно приходят во всех более-менее крупных проектах. Для второго за редкими исключениями нет никаких причин кроме как "прочитал, хочу попробовать". Тесты — это лишь отмазка и не более того. Если ваш код приходится менять именно ради тестов, то это у вас уже следствие вылезло. Первопричина в 100% случаев — бардак в проекте. Его и надо лечить.


I>Не проще и не дешевле. И писать тяжелей среднестатистическому деву(автоматизаторы вообще отдельная профессия), и дебажить(ну там к примеру рандомные тормоза http, которые локально не репродьясятся валят тесты на серваке), и ранаются они гораздо дольше. А если есть много интеграций с третьесторонними сервисами, то все становится.


Так тут тоже путаница с терминологией Давайте не путать интеграционные тесты (всё то же тестирование API, только на уровне крупных блоков, а не отдельных типов) и автотесты/ui-тестирование (aka blackbox testing — используем исключительно публичные интерфейсы продукта, UI — если ничего другого нет). Вы пишете про второе, я — про первое
Последнее — это делянка QA и разработчикам там делать особо нечего, только исправлять места, которые плохо поддаются тестированию.
Re[6]: О "наивном" DI и об архитектурном бессилии
От: itslave СССР  
Дата: 30.07.16 19:41
Оценка: 22 (1) +1
Здравствуйте, Sinix, Вы писали:

S>Сорри за подколку. Если серьёзно, то оформление инфраструктурного API в виде интерфейсов и DI — вещи ортогональные. К первому рано или поздно приходят во всех более-менее крупных проектах. Для второго за редкими исключениями нет никаких причин кроме как "прочитал, хочу попробовать". Тесты — это лишь отмазка и не более того. Если ваш код приходится менять именно ради тестов, то это у вас уже следствие вылезло. Первопричина в 100% случаев — бардак в проекте. Его и надо лечить.

Есть целая методология TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла, она популярная, модная, молодежная и все такое. Я к примеру несколько проектов сделал с поголовным DI и тысячами юнит тестов. Тяжеловестности добавляет(процентов 20 времени в среднем на задачу), но в общем и целом — полет нормальный.
Вот чего я не нашел пока — это каких бы то ни было метрик полезности этого хозяйства. Юнит тесты ранаются, все зелененькое. Может когда у кого из девов локально чота ломается и фиксается. В случае рефакторинга эти самые тесты пачками выкидываются и пачками же переписываются. Но вот как понять, насколько оно себя оправдывает — неясно.

S>Так тут тоже путаница с терминологией Давайте не путать интеграционные тесты (всё то же тестирование API, только на уровне крупных блоков, а не отдельных типов) и автотесты/ui-тестирование (aka blackbox testing — используем исключительно публичные интерфейсы продукта, UI — если ничего другого нет). Вы пишете про второе, я — про первое

Я не путаю, автотесты — это подвид интеграционных тестов
Но ок, давай про крупноблочные тесты.
Тут есть 2 засады:
— БД. Она должна быть, в ней должны быть подготовлены корректные данные для каждого теста. Их надо корректно инсертать и чистить. Это все время. При паре тысяче тестов время выполнения может лихко затянуться на полчаса, что очень нехорошо. Кроме того зачастую очень легко устроить race conditions при параллельном запуске тестов — передерутся из-за данных в базе, что в свою очередь может вынудить запускать их последовательно, что опять таки бьет по времени исполнения.
— Конфигурация. Если тестировать большую подсистему, то для прогона типичного сценария надо исполнить танец нанайских мальчиков инициализации системы. Зачастую это больно и тяжело. А если внутри используются переменные типа HttpContext.Current или же DateTime.Now, то вечер перестает быть томным — проинициализировать их корректно больно, неприятно и не всегда возможно.
Отредактировано 30.07.2016 19:43 itslave . Предыдущая версия .
Re[7]: О "наивном" DI и об архитектурном бессилии
От: Sinix  
Дата: 31.07.16 08:32
Оценка: +1
Здравствуйте, itslave, Вы писали:

I>Есть целая методология TDD, которая именно юнит тестирование(и как следствие DI) ставит во главу угла, она популярная, модная, молодежная и все такое.

Она отлично работает для инфраструктуры, почти для любого масштаба, неплохо работает для мелочёвки и абсолютно не работает даже для средних проектов. Чтоб было понятно, что такое средний проект: представь себе типовой биз-кейз в виде 20-страничного документа 12 шрифтом, в котором 90% текста — не вода, а логика, причём высокоуровневая, без расписывания до отдельных инструкций. Представь объём кода для этого документа и умножь этот код на 5 — получишь самый минимум для тестов. И теперь контрольный в голову — таких кейсов несколько десятков на каждого разработчика. TDD сам по себе в таких условиях не катит.

Поэтому только вытаскивание всего что можно в инфраструктуру (которую как раз покрывать юнит-тестами), только ассерты по всему коду и только интеграционные тесты для бизнес-логики (для проверки результата и для того, чтобы заставить сработать ассерты.

I>Я к примеру несколько проектов сделал с поголовным DI и тысячами юнит тестов.

Не, тысяча юнит-тестов — это вообще ни о чём. Это типовой объём тестов за пару месяцев для команды из двух-трёх человек. Если мы конечно про инфраструктурную часть говорим.

I>Но вот как понять, насколько оно себя оправдывает — неясно.

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



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

Ну так это обязательно, особенно если запросы нетривиальные, какие ещё варианты-то?

Отлично работает комбинация CI-сервер + SSD + MS SQL Dev edition. Минуты, но никак не полчаса. Иначе уже есть повод профилировать и убирать узкие места. Ну и тысяча интеграционных тестов — это уже много. По соотношению к простым юнит-тестам их обычно хорошо если 1 к 20.


I> Кроме того зачастую очень легко устроить race conditions при параллельном запуске тестов — передерутся из-за данных в базе, что в свою очередь может вынудить запускать их последовательно, что опять таки бьет по времени исполнения.

Ну да. Исхитриться можно с разбиением по группам, но какая альтернатива-то?


I> — Конфигурация. Если тестировать большую подсистему, то для прогона типичного сценария надо исполнить танец нанайских мальчиков инициализации системы. Зачастую это больно и тяжело.

Не, эт тяжело только на первых порах, затем решается тем или иным способом. Для больших проектов для интеграционных тестов инфраструктуру вообще запускают локальной службой, чтоб не ждать, пока оно заведётся. Это конечно ещё сложнее и требует отдельного этапа при сборке чтоб закинуть туда свежие assemblies, но иногда по-другому никак. Впрочем, сейчас в моде быстрое развёртывание / запуск, внедренцы очень просят. Поэтому потихоньку переползаем со всех костылей на стандартное API, но чтоб оно не тормозило.


I>А если внутри используются переменные типа HttpContext.Current или же DateTime.Now, то вечер перестает быть томным — проинициализировать их корректно больно, неприятно и не всегда возможно.

В бизнес-логике??? Да ну нафиг, расстреливать за такое. Оно ж потом, если потребуется поправить (например, пользователь просит печать форм заранее, за пару дней до фактической даты) — кучу кода придётся просматривать и править.
Re[6]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 01.08.16 05:44
Оценка: +1 :)
Здравствуйте, _hum_, Вы писали:

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


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


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


IQ>>Думаю да, инструменты и механизмы надо использовать по мере необходимости, а не потому, что так модно.


__>так это верно для любого случая. почему вы выделили именно DI?


Потому, что про него пост. Вы можете написать пост о любом другом случае.

__>>>кстати, в той же wiki указаны недосатки (наряду с достоинствами), в том числе и те, о которых вы говорите: Dependency_injection_frameworks


IQ>>Имхо главного не написано — маниакальная страсть к IOC навязываемая ранним внедрением DI провоцирует нарушение всех принципов SOLID.


__>на что все-таки логическое ударение — на "маниакальная страсть к IOC" или на "ранее внедрение DI"?


логическое ударение на непонимание того, какие проблемы инструмент решает.
Re: О "наивном" DI и об архитектурном бессилии
От: UberPsychoSvin  
Дата: 01.08.16 08:30
Оценка:
Здравствуйте, IQuerist, Вы писали:

У меня от DI в проекте:
— Градус общей монструозности вырос. И конструкторы здоровые и интерфейсы "лишние".
+/- через интерфейсы можно что угодно легко вкорячить куда угодно. Это и плюс. И минус — могут прорастать неявные зависимости.
+ Удобно синглтоны создавать. Прописал в конфиге .InSingletonScope() и всё.
+ В тестах можно мокать объекты.
+ Можно через моки погонять на живую часть системы. Типа такого.
var kernel = KernelFactory.Build();
kernel.Rebind<IConfigProvider>().To<Mock1>().InSingletonScope();//ребиндим от чего у нас компонент зависит.
kernel.Rebind<IService>().To<Mock2>().InSingletonScope();
var c = kernel.Get<IComponent>();

И играемся с компонентом в тестовом проекте.

Одним словом:
— Монструозненько.
+ Универсальненько.

----------

А что взамен предлагаете. Такие штуки?
static class LoggingFactoryProvider { ILogFactory get; }
static class WebServiceProvider { IWebService get; }
Re[2]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 02.08.16 06:46
Оценка:
Здравствуйте, UberPsychoSvin, Вы писали:

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


UPS>У меня от DI в проекте:

UPS>- Градус общей монструозности вырос. И конструкторы здоровые и интерфейсы "лишние".

UPS>А что взамен предлагаете. Такие штуки?


Этот топик не против DI в целом, он против "DI ради DI". Вы похоже хоть какими-то возможностями DI пользуетесь, но большинство новичков только плодит "намертво стабильные абстракции" из DAL хелперов и constructor injection. Исходя из проектов, на которых мне пришлось работать это стало архитектурным шаблоном. Ничего кроме монструозности они не получают и по какой-то странной причине отказываются это замечать.
Re: О "наивном" DI и об архитектурном бессилии
От: r.kamenskiy Россия  
Дата: 02.08.16 11:22
Оценка:
Здравствуйте, IQuerist, Вы писали:

IQ>О "наивном" DI и об архитектурном бессилии


IQ>Никогда я не имел желания холиварить на тему DI...


А тем временем DI уже попал в ASP Core. И не просто попал, а полноценно поддержан всеми уровнями MVC. Даже появилась возможность инжектить прям во View.
т.е. подразумевается, что DI будет использоваться (и используется) почти во всех Asp Core приложениях.

Как дальше жить будете?
Re[2]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 02.08.16 14:07
Оценка:
Здравствуйте, r.kamenskiy, Вы писали:

RK>А тем временем DI уже попал в ASP Core. И не просто попал, а полноценно поддержан всеми уровнями MVC. Даже появилась возможность инжектить прям во View.

RK>т.е. подразумевается, что DI будет использоваться (и используется) почти во всех Asp Core приложениях.

RK>Как дальше жить будете?


Надеюсь неплохо Я категорически приветствую DI, я против горе-прогеров которые используют его например для инжектирования DAL хелперов (Colonoscopy Injection).
Отредактировано 12.08.2016 13:56 IQuerist . Предыдущая версия .
Re: О "наивном" DI и об архитектурном бессилии
От: Visor2004  
Дата: 09.08.16 21:24
Оценка: +2
Здравствуйте, IQuerist, Вы писали:

IQ>имхо совершенно очевидно, что наивный сервис слепленный из хелперных методов DAL, ни в коем случае не является "абстракцией". Он предельно конкретный с предельно конкретными entity типами даже если структура этих типов продублирована, а данные копируются с помощью мапперов (эдакий карго-культ "абстрации"). Имхо здесь совершенно четко определяемая проблемы — интерфейсы верхних уровней начинают определять низкоуровневые интерфейсы DAL. Разрозненные хелперные методы не перестанут быть хелперными методами от того, что их вызывают через интерфейс.


И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[2]: О "наивном" DI и об архитектурном бессилии
От: IQuerist Мухосранск  
Дата: 10.08.16 07:29
Оценка:
Здравствуйте, Visor2004, Вы писали:

V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.


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

Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".

PS кстати в последствии это порождает наивные REST интерфейсы и переезд критической части бизнес логики в клиентские скрипты. Как я и определил ранее — Colonoscopy Injection (зависимость от очень конкретных сущностей и повсеместное нарушение DI).
Отредактировано 10.08.2016 8:05 IQuerist . Предыдущая версия . Еще …
Отредактировано 10.08.2016 7:34 IQuerist . Предыдущая версия .
Отредактировано 10.08.2016 7:30 IQuerist . Предыдущая версия .
Re: При чем тут Di?
От: 0x7be СССР  
Дата: 10.08.16 09:33
Оценка:
Здравствуйте, IQuerist, Вы писали:

IQ>О "наивном" DI и об архитектурном бессилии

При чем тут DI?

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