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

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

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

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

Вместо:

class Person(Address) {
...

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

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

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

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

Источник

4 ответа

Решение

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

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

Источник

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

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

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

Тем не менее, DI используется повсеместно в Ruby.

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

Источник

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

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

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...:-)

Источник

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

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

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

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

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

Источник
Другие вопросы по тегам