С моей профессиональной точки зрения DI фреймворки не нужны.
Они затрудняют распутывание кода,
понижают гибкость автоматического рефакторинга (в частности ReSharper-ом)
и это не перекрывается гибкостью подстановки mock-объектов
но обнаруживаю ярых адептов этого всего.
уже и в вакансиях суют такое требование
кто-то может популярно расписать преимущества либо природу явления популярности?
(часть плюсов знаю и гипотезы-то я имею, но мнение всё равно такое)
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Ты просто старый.
ЭФ>Раньше такая же проблема с темплейтами в C++ была, ЭФ>не все понимали зачем ими пользоваться, если можно и без них.
DI это довольно старый паттерн. Если ТС не просидел 20 лет на необитаемом острове, он бы знал.
Не очень понятно, чем ты предлагаешь их заменить. Я знаю несколько альтернатив: глобальные переменные; реестр объектов. Обе эти альтернативы мне не нравятся и имеют серьёзные минусы. В случае с DI минусов лично я не вижу. С тем, чтобы DI затруднял распутывание кода, я не сталкивался. Возможно ты сможешь пояснить, что именно ты имеешь в виду? Я, правда, пользуюсь Java.
МП>>С моей профессиональной точки зрения DI фреймворки не нужны.
AA>Какой велосипед предлагаете взамен?
так а зачем вообще делать dependency injection?
не как паттерн проектирования — чтобы развязать циклическую зависимость сборок,
а для инициализации новых объектов
на последнем проекте я видел, что она применялась вообще для большинства классов, у которых даже не было нормальных конструкторов
vsb>Не очень понятно, чем ты предлагаешь их заменить. Я знаю несколько альтернатив: глобальные переменные; реестр объектов. Обе эти альтернативы мне не нравятся и имеют серьёзные минусы. В случае с DI минусов лично я не вижу. С тем, чтобы DI затруднял распутывание кода, я не сталкивался. Возможно ты сможешь пояснить, что именно ты имеешь в виду? Я, правда, пользуюсь Java.
нормальные обычные конструкторы, ну либо статические конструкторы, если нужен пул объектов...
МП>>кто-то может популярно расписать преимущества либо природу явления популярности?
F2>Я недавно спрашивал подобное: http://rsdn.org/forum/java/7835059.1
Здравствуйте, Министр Промышленности, Вы писали:
vsb>>Не очень понятно, чем ты предлагаешь их заменить. Я знаю несколько альтернатив: глобальные переменные; реестр объектов. Обе эти альтернативы мне не нравятся и имеют серьёзные минусы. В случае с DI минусов лично я не вижу. С тем, чтобы DI затруднял распутывание кода, я не сталкивался. Возможно ты сможешь пояснить, что именно ты имеешь в виду? Я, правда, пользуюсь Java.
МП>нормальные обычные конструкторы,
не понял какие конструкторы у тебя нормальные но DI не накладывает никаких ограничений на это.
МП>ну либо статические конструкторы,
их DI отменяет или что?
МП>если нужен пул объектов...
И?
Здравствуйте, Министр Промышленности, Вы писали:
МП>>>С моей профессиональной точки зрения DI фреймворки не нужны.
AA>>Какой велосипед предлагаете взамен?
МП>так а зачем вообще делать dependency injection?
Уменьшить связанность компонентов.
Повысить гибкость поведения. клиент просит интерфейс, а в конфиге можно указать реализацию.
Идеальная система настолько модульна, что можно в рантайме выгружать и загружать модули
(такое есть в блэкбокс — можно выгрузить любую библиотеку если нет активных ссылок).
vsb>>>Не очень понятно, чем ты предлагаешь их заменить. Я знаю несколько альтернатив: глобальные переменные; реестр объектов. Обе эти альтернативы мне не нравятся и имеют серьёзные минусы. В случае с DI минусов лично я не вижу. С тем, чтобы DI затруднял распутывание кода, я не сталкивался. Возможно ты сможешь пояснить, что именно ты имеешь в виду? Я, правда, пользуюсь Java.
МП>>нормальные обычные конструкторы, GIV>не понял какие конструкторы у тебя нормальные но DI не накладывает никаких ограничений на это. МП>>ну либо статические конструкторы, GIV>их DI отменяет или что?
вопрос был в разрезе целесообразности использования DI
если можно использовать нормальные конструкторы, зачем там применять DI?
или даже зачем заменять нормальное конструирование дополнительными DI сборками и конфигурированием этого всего
МП>>так а зачем вообще делать dependency injection?
AA>Уменьшить связанность компонентов.
принимается
AA>Повысить гибкость поведения. клиент просит интерфейс, а в конфиге можно указать реализацию.
не надо так делать!
если очень надо, то можно
но это же несёт уже упомянутые мной издержки
уже со времён WCF сервисов заметил, что сложность конфигурирования зачастую превышает сложность кодирования
AA>Идеальная система настолько модульна, что можно в рантайме выгружать и загружать модули
это красиво, но не безопасно
угроза со стороны расщепления внимания
выгрузка и развёртывание — и так напряженный момент
в идеале она должна сводиться к аккуратному копированию файлов
или даже лучше — к удалению каталога и просто копированием нового целиком
а вы предлагаете в рантайме мутить сборками
AA>(такое есть в блэкбокс — можно выгрузить любую библиотеку если нет активных ссылок).
если это делается автоматически, то это плюс
если об этом надо думать — это минус
AA>>>Какой велосипед предлагаете взамен? AA>ПС. не ответили на мой вопрос.
я не предлагаю велосипедов, вполне можно использовать популярные DI фреймворки там где это реально необходимо
а реальная необходимость бывает редко и всего в 2-3 местах системы
я видел что часто суют прочто чтобы было
это конечно боль программных проектов — разработчики тренирубтся за счет работодателя реально в ущерб энтропии проекта
но когда ещё начинают требовать — это на мой взгляд невменяемость сознания
Здравствуйте, Министр Промышленности, Вы писали:
vsb>>>>Не очень понятно, чем ты предлагаешь их заменить. Я знаю несколько альтернатив: глобальные переменные; реестр объектов. Обе эти альтернативы мне не нравятся и имеют серьёзные минусы. В случае с DI минусов лично я не вижу. С тем, чтобы DI затруднял распутывание кода, я не сталкивался. Возможно ты сможешь пояснить, что именно ты имеешь в виду? Я, правда, пользуюсь Java.
МП>>>нормальные обычные конструкторы, GIV>>не понял какие конструкторы у тебя нормальные но DI не накладывает никаких ограничений на это. МП>>>ну либо статические конструкторы, GIV>>их DI отменяет или что?
МП>вопрос был в разрезе целесообразности использования DI
МП>если можно использовать нормальные конструкторы, зачем там применять DI? МП>или даже зачем заменять нормальное конструирование дополнительными DI сборками и конфигурированием этого всего
Нормальное DI как раз и работает через конструкторы. Как вообще можно писать бизнес приложения без DI ума не приложу, покажите пример, а мы посмотрим.
Здравствуйте, Министр Промышленности, Вы писали:
МП>С моей профессиональной точки зрения DI фреймворки не нужны.
Надо было писать "недостаточно профессинальной"
МП>Они затрудняют распутывание кода, МП>понижают гибкость автоматического рефакторинга (в частности ReSharper-ом) МП>и это не перекрывается гибкостью подстановки mock-объектов
DI нужен в первую очередь для фреймворков, а не бизнес-логики.
МП>но обнаруживаю ярых адептов этого всего. МП>уже и в вакансиях суют такое требование
Уже? Доброе утро. Погугли что означает D в SOLID
МП>кто-то может популярно расписать преимущества либо природу явления популярности? МП>(часть плюсов знаю и гипотезы-то я имею, но мнение всё равно такое)
Давай сразу возьмем уданчый пример. ASP.NET Core например, он построен на DI.
В любом классе, который получается через DI можно написать так:
public MyClass
{
public MyClass(ILogger<MyClass> logger) { ... }
}
Тебе нигде не надо явно создавать логгер, знать его тип или знать что-то о его времени жизни.
Попробуй полчить аналогичные возможности без DI.
Более того, настроив DI, ты дальше можешь написать так:
public MyOtherClass
{
public MyOtherClass(MyClass x) { ... }
}
При этом можешь сделать MyClass как синглтоном, так и создавать экземпляр на каждый запрос.
Здравствуйте, gandjustas, Вы писали:
МП>>но обнаруживаю ярых адептов этого всего. МП>>уже и в вакансиях суют такое требование G>Уже? Доброе утро. Погугли что означает D в SOLID
Попробуй сам погуглить, что же именно означает D в SOLID
Здравствуйте, Министр Промышленности, Вы писали:
vsb>>Не очень понятно, чем ты предлагаешь их заменить. Я знаю несколько альтернатив: глобальные переменные; реестр объектов. Обе эти альтернативы мне не нравятся и имеют серьёзные минусы. В случае с DI минусов лично я не вижу. С тем, чтобы DI затруднял распутывание кода, я не сталкивался. Возможно ты сможешь пояснить, что именно ты имеешь в виду? Я, правда, пользуюсь Java.
МП>нормальные обычные конструкторы, ну либо статические конструкторы, если нужен пул объектов...
Я не понимаю тебя.
У меня есть один объект. Например назовём его UserDao. И есть второй объект. Назовём его AuthService. Для AuthService нужна ссылка на UserDao. Каким образом он эту ссылку получит?
Сконструировать он его не может. Во-первых я просто не хочу, чтобы в системе было много UserDao, например там может быть кеширование или ещё что угодно. Во-вторых для создания UserDao мне нужно соединение к БД, возможно ещё что-то. Передавать всю эту кучу скопом в AuthService (и в любой другой объект, которому нужен UserDao) это маразм.
Если я правильно понял про "статические конструкторы", ты предлагаешь сделать что-то вроде UserDao.getInstance(). То бишь реестр объектов, причём плохой и неудобный реестр. Так делать можно, но при этом возникает уйма проблем:
1. Такой код сложно тестировать. Если я хочу, чтобы AuthService принимал фейковый UserDao, мне нужно вызывать в тесте UserDao.setInstance(testUserDao). При этом мне в принципе нужно помнить при тестировании AuthService про все его зависимости. А ещё надо не забыть по окончании работы теста убрать все эти тестовые переменные, иначе это может поломать другие тесты. Ещё возникают вопросы с многопоточностью. В общем проблем много. Решать как-то их, наверное, можно, но неудобно.
2. Такой код сложно переиспользовать. Если мне всё же понадобится в реальном коде другой UserDao конкретно для AuthService, то это будет просто невозможно сделать в рамках данного подхода.
3. Непонятно, собственно, к чему мы пришли в итоге. У нас есть вызов UserDao.getInstance(), который возвращает что-то. Что он возвращает? Неизвестно. Кто-то там ему сделал setInstance раньше, его и возвращает. Какая разница с DI в плане понимания работы кода? Никакой разницы.
4. Сложно понять, от чего зависит AuthService. Нужно внимательно читать его код, изучать список импортов. В случае с DI ты просто смотришь на параметры конструктора и всё как на ладони. Это бывает удобно.
Здравствуйте, Министр Промышленности, Вы писали:
МП>Они затрудняют распутывание кода,
Нет. Зачастую создание большинства объектов в одном месте.
Проект с сервис-локаторами, синглтонами и прочим запутанее, чем проект с DI. Хотя бы потому что больше boilerplate кода.
МП>понижают гибкость автоматического рефакторинга (в частности ReSharper-ом)
МП>>вопрос был в разрезе целесообразности использования DI МП>>если можно использовать нормальные конструкторы, зачем там применять DI? МП>>или даже зачем заменять нормальное конструирование дополнительными DI сборками и конфигурированием этого всего
M>Как вообще можно писать бизнес приложения без DI ума не приложу
подозрительное заявление
M>покажите пример, а мы посмотрим.
это не вполне легально по нынешним временам
но всё что я сам писал было без DI кроме мест в проектах где это было уже мне навязано через легаси
Здравствуйте, Министр Промышленности, Вы писали:
МП>а реальная необходимость бывает редко и всего в 2-3 местах системы
Очевидно, что DI это реализация принципа инверсии зависимостей.
Если у вас возникают циклические зависимости между компонентами, то вам не избежать DI.
