Когда использовать Dependency Injection? Когда нет?

Question

Из того, что я понимаю, компромисс здесь - вопрос дополнительной сложности. Может быть?

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

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

Answer 1

Внедрение зависимостей, если все сделано правильно (эффективно?), Безусловно, разъединяет ваши объекты. По моему мнению, область, где это преимущество реализуется больше всего, - это когда вы используете Mock или объекты-заглушки в своих юнит-тестах. Довольно часто это означает, что вы будете меньше проходить модульное тестирование в каждом отдельном тесте, что упрощает их. Такое продвижение эффективных модульных тестов часто приносит свои дополнительные преимущества.

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

Answer 2

Используйте Dependency Injection, если вы хотите создать альтернативные реализации данного типа сервиса. Каноническим примером этого является замена фиктивного объекта вместо поставщика услуг для целей тестирования.

Например, Dependency Injection позволяет вам использовать «реальную» базу данных или «поддельную» базу данных, которая имитирует поведение реальной базы данных. В обоих случаях «внедренная» зависимость имеет один и тот же интерфейс, но вы можете поменять местами реализацию.

Answer 3

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

Это зависит от того, насколько четко определены или интуитивно понятны зависимости. Исходя из родного C ++ фона, я нашел в .NET части, где зависимости явно очевидны и обеспечивали большую гибкость, но другие области, которые я просто не понимал и не мог сразу понять требования к использовать определенный фрагмент кода или объекта, из-за множества факторов, включая именование классов и мои знания о системе.

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

Так или иначе, это моя идея.

Answer 4

"Внедрение зависимостей" охватывает широкий спектр от передачи параметров конструктора в XML-сконфигурированную среду. Одна счастливая среда, которую я недавно «обнаружил», охватывает многие из «ложных» случаев, не требуя реальной основы. Это немного подрывно, но в единичных случаях работать намного проще.

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

Основной код:

public class A {
    // ...
    private service;

    protected Service getService() {
        return new RealService();
    }

    public A() {
        service = getService();
    }
    // ...
}

Тестовый код:

public class Test {
    void test() {
        final Service fakeService = new FakeService();
        A thingToTest = new A() { 
            protected Service getService() { return fakeService; }
        }
        thingToTest.doOneThing();
        // ...
    }
}