Любая потребность в инъекции зависимостей в динамических языках?

Чтобы написать тестовый код С#, я сильно использую DI.

Однако в последнее время я возился с IronPython и обнаружил, что, поскольку вы можете издеваться над любыми методами/классами/функциями и т.д.... вам нравится, потребность в DI отсутствует.

Это так для динамических langagues, таких как Python?

Вместо:

class Person(Address) {
...

У вас может быть:

class Person() {
...
    // Address initialised in here.

Для динамических языков и, следовательно, следующий манаальный DI для динамических langagues просто не нужен.

Любые советы по этому поводу?

Ответ 1

Инъекция зависимостей также связана с тем, как вы соединяете вещи --- что не имеет ничего общего с мечимостью объектов, зависящих от них. Там разница между наличием Foo -instance, которому требуется Bar -соединение какого-либо типа, создает его непосредственно и полностью игнорирует, как оно получает это соединение, если оно есть.

Если вы используете инъекцию зависимостей, вы также получаете лучшую тестируемость. Но обратное неверно. Более простая проверка на возможность перезаписывать что-либо не приводит к другим преимуществам инъекции зависимости. По этим причинам существует много компонентов/DI-фреймворков для Python.

Ответ 2

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

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

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

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

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

Ответ 3

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

Используя псевдокод, зависимость 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...: -)

Ответ 4

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

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

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

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

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