Какая-либо потребность во внедрении зависимости на Динамических Языках?

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

Основное различие состоит в том, что DI в динамически типизированных языках выполняется легко и безболезненно: вам не нужен тяжелый фреймворк и миллионы строк конфигурации XML.

В Ruby, например, есть только две структуры DI. Оба были написаны Java-программистом. Ни один из этих двух фреймворков не используется в одном единственном проекте. Даже автор этих фреймворков.

Однако DI используется повсеместно в Ruby.

Джеймис Бак, автор обеих этих фреймворков, выступил с докладом под названием Восстановление с Enterprise на RubyConf 2008 о том, как и почему он написал эти фреймворки и почему это была плохая идея, за которой стоит посмотреть. Также есть сопутствующее сообщение в блоге , если вы хотите прочитать. (Просто заменяйте «Python» каждый раз, когда он говорит «Ruby», и все будет так же верно.)

кто является автором этих фреймворков, выступил с докладом под названием Восстановление с предприятия на RubyConf 2008 о том, как и почему он написал эти фреймворки, и почему это была плохая идея, которую стоит посмотреть. Также есть сопутствующее сообщение в блоге , если вы хотите прочитать. (Просто заменяйте «Python» каждый раз, когда он говорит «Ruby», и все будет так же верно.)

Кто является автором обоих этих фреймворков, выступил с докладом под названием Восстановление с предприятия на RubyConf 2008 о том, как и почему он написал эти фреймворки и почему это была плохая идея, которую стоит посмотреть. Также есть сопутствующее сообщение в блоге , если вы хотите прочитать. (Просто заменяйте «Python» каждый раз, когда он говорит «Ruby», и все будет так же верно.)

Я думаю, вы задаете вопрос, который, кажется, связан с передовой практикой, но на самом деле касается производительности во время выполнения.

Избавиться от внедрения зависимостей? Как может менеджер выпуска программного обеспечения спать по ночам?

Проверки на выполнение функций обязательно должны замедлить программу на один или два шага.

// my generic function entry point - IronPython
if func="a":
  ...
if func="b":
  ...
if func="c":
  ...

Вы можете использовать стандартный Python с классами ... или вы можете назначить указатели на функции членам указателя функций. Что это за зверь ... ?? Я знаю я знаю. Python, я думаю, трудно определить, но мне он нравится. И я люблю и высоко отношусь к внедрению зависимостей, не то чтобы я давно уже думал присвоить этой практике такое длинное имя.

Я попробую еще раз. Мой последний ответ пропустил вопрос на милю и увеличил масштаб темы.

Используя псевдокод, зависимость Injection говорит с:

class Person
  def Chat() { 
    someOperation("X","Y","Z")
  end
end
...
Person.new().Chat()

и с:

class Person
  initialize(a,b,c)
    @a=a
    @b=b
    @c=c
  end
  def Chat()
    someOperation(@a,@b,@c)
  end
end
...
Person.new("X","Y","Z").Chat()

,... и вообще с помещением объекта и вызовом в различные файлы для целей SCM.

Будь то "X", "Y" или "Z", могут быть высмеяны (... если бы они были объектами...(!)...(!)...) вообще не имеют никакого отношения к тому, хорош ли DI. Действительно. :-)

DI просто проще на Python или Ruby, как и многие другие задачи, потому что есть больше скриптового подхода, как говорит Йорг; а также, конечно, меньше культуры и тенденции, говорящей, что константы и адаптеры должны быть заселены в модели и глобальные константы.

В практическом плане для меня DI - это первый шаг к разделению этих параметров приложения, констант API и фабрик на отдельные файлы, чтобы помочь сделать ваш отчёт по отслеживанию ревизий менее спагетти-подобным ("Были ли эти дополнительные проверки на AppController, чтобы изменить конфигурацию?..? Или чтобы обновить код...?") и более информативным, и более легким для чтения.

Моя рекомендация: Продолжайте использовать DI... :-)

.