Нужно ли вводить зависимости в динамических языках?

Question

Для написания тестируемого кода на C # я интенсивно использую DI.

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

Это относится к динамическим языкам, таким как Python?

Вместо:

class Person(Address) {
...

Вы можете иметь:

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Используя псевдокод, инъекция зависимостей выдает:

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 проще в Python или Ruby, как и во многих других задачах, потому что есть больше сценариев, как говорит Йорг; а также, конечно, меньше культуры и тенденции, согласно которой константы и адаптеры должны быть включены в модели и глобальные константы.

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

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

Answer 4

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

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

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

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

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