Когда использовать инъекцию зависимостей

Question

У меня было определенное чувство, что эти последние пару дней, что инъекция зависимостей действительно должна называться «Я не могу принять решение». Я знаю, это может показаться глупым, но на самом деле речь идет о том, почему я должен использовать Dependency Injection (DI). Часто говорят, что я должен использовать DI, чтобы достичь более высокого уровня свободной связи, и я получаю эту часть. Но действительно ... как часто я меняю свою базу данных, как только мой выбор упал на MS SQL или MySQL. Очень редко?

Есть ли у кого-то очень веские причины, по которым DI - это путь?

Answer 1

Два слова, модульные испытания.

Одна из наиболее веских причин для DI заключается в том, чтобы упростить тестирование модулей без необходимости попадания в базу данных и беспокоиться о настройке «тестовых» данных.

Answer 2

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

Answer 3

В то время как я согласен с вами с примером DB, одна из больших вещей, которые я нашел полезной для использования DI, - это помочь мне протестировать слой, который я создаю поверх базы данных.

Вот пример ...

У вас есть база данных.

У вас есть код, который обращается к базе данных и возвращает объекты

У вас есть бизнес-объекты домена, которые принимают объекты предыдущего элемента и сделать некоторую логику с ними.

Если вы объедините доступ к данным с логикой вашего бизнес-домена, объекты вашего домена могут стать трудными для тестирования. DI позволяет вам вводить свои собственные объекты доступа к данным в ваш домен, чтобы вы не зависели от базы данных для тестирования или, возможно, демонстраций (выполнялась демонстрация, в которой некоторые данные были извлечены из xml вместо базы данных).

Тезисы сторонних компонентов и фреймворков, подобных этому, также помогут вам.

Помимо примера тестирования, есть несколько мест, где DI можно использовать с помощью подхода Design by Contract. Возможно, вам будет необходимо создать механизм обработки, который вызывает методы объектов, которые вы вставляете в него. Хотя это может и не по-настоящему «обрабатывать», он запускает методы, которые имеют различную реализацию в каждом объекте, который вы предоставляете.

Я увидел пример этого, где каждый объект бизнес-домена имел функцию «Сохранить», которую вызвал после того, как он был введен в процессор. Процессор модифицировал компонент с информацией о конфигурации, а Save обработал основное состояние объекта. В сущности, DI дополнял реализацию полиморфного метода объектов, соответствующих интерфейсу.

Answer 4

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

Это действительно помогает мне сосредоточиться на взаимодействии вещей в разработке программного обеспечения, а не на том, «кому нужно носить что-то, потому что кому-то это нужно позже».

Кроме того, это также позволяет сэкономить много рабочих текстов. Нужен ли мне синглтон? Я просто настраиваю класс как один. Могу ли я тестировать такой «синглтон»? Да, я все еще могу (так как я просто КОНФИГУРИРОВАЛ его существовать только один раз, но тест может создать альтернативную реализацию).

Но, кстати, до того, как я использовал DI, я действительно не понимал его достоинства, но, стараясь, чтобы это стало для меня настоящим открытием, мои проекты гораздо объективнее, чем раньше. Кстати, с текущим приложением я НЕ блок-тест (плохой, плохой), но я все еще не мог жить с ДИ. Это намного легче перемещать вещи и держать классы маленькими и простыми.

Answer 5

Injection Dependency дает вам возможность тестировать отдельные единицы кода изолированно.

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

public class Foo 
{ 
    private Bar _bar; 

    public Foo(Bar bar) 
    { 
     _bar = bar; 
    } 

    public bool IsPropertyOfBarValid() 
    { 
     return _bar.SomeProperty == PropertyEnum.ValidProperty; 
    } 
} 

Теперь давайте скажем, что Bar конкретизируется и его свойства устанавливаются данные из некоторого источника данных в его конструктор. Как я могу протестировать метод IsPropertyOfBarValid()Foo (игнорируя тот факт, что это невероятно простой пример)? Ну, Foo зависит от экземпляра Bar, переданного конструктору, который, в свою очередь, зависит от данных из источника данных, для которого установлены его свойства. То, что мы хотели бы сделать, - это сделать какой-то способ изолировать Foo от ресурсов, от которых он зависит, чтобы мы могли его тестировать по отдельности.

Здесь вы найдете инъекции зависимостей. Мы хотим, чтобы какой-то способ подделать экземпляр Bar передан Foo таким образом, что мы можем управлять свойствами, установленными на этом подделке Bar, и достичь того, что мы намеревались сделать, проверить, что реализация IsPropertyOfBarValid() делает то, что мы ожидаем от него, т.е. возвращаем true, когда Bar.SomeProperty == PropertyEnum.ValidProperty и false для любого другое значение.

Существует два типа поддельных объектов, Mocks и Stubs. Stubs предоставляют входные данные для тестируемого приложения, так что тест может быть выполнен на другом. С другой стороны, макеты предоставляют вход для теста, чтобы принять решение об ошибке pass \ fail.

Martin Fowler has a great article on the difference between Mocks and Stubs

Answer 6

Я думаю, что DI стоит использовать, если у вас есть много услуг/компонентов которых реализации должны быть выбраны во время выполнения на основе внешней конфигурации. (Обратите внимание, что такая конфигурация может иметь форму XML-файла или комбинации аннотаций кода и отдельных классов; выберите то, что более удобно.)

В противном случае я бы просто использовал ServiceLocator, который намного «легче» и легче понять, чем целая каркас DI.

Для модульного тестирования я предпочитаю использовать насмешливый API, который может издеваться над объектами по требованию, вместо того, чтобы требовать их «впрыскивания» в тестируемый блок из теста. Для Java одна такая библиотека моя, JMockit.

Answer 7

Я только что понял сегодня вечером. Для меня инъекция зависимостей - это метод для объектов-экземпляров, которые требуют большого количества параметров для работы в определенном контексте.

Когда вы должны использовать инъекции зависимостей? Вы можете использовать инъекцию зависимостей, если вы ставите объект статическим способом. Например, если вы используете класс, который может преобразовывать объекты в файл XML или JSON, и если вам нужен только файл XML. Вам нужно будет стимулировать объект и настроить много вещей, если вы не используете инъекцию зависимостей.

Когда вы не должны использовать инъекцию подкрепления? Если объект инстанцируется с параметрами запроса (после формы заявки), вы не должны использовать инъекцию подкрепления, потому что объект не ставится статическим образом.

Answer 8

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

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

Насколько это уместно для вашего проекта, зависит от ожидаемого срока службы вашего кода. В зависимости от типа работы, которую вы выполняете при повторном использовании нуля из одного проекта в следующий для большинства кода, который вы пишете, на самом деле может быть вполне приемлемым.

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

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