Преимущества реализации и внедрения зависимостей по сравнению со стоимостью поддержки реализаций

Question

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

Зная, что вы знаете о DI в среде с несколькими разработчиками, вы бы выбрали DI дляновое приложение, которое вы хотели бы построить относительно быстро?

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

Answer 1

DI в основном не о фреймворках. Если вы просто добавляете свои зависимости, например, в качестве параметров к констриктору, то вы делаете DI. На самом деле вам даже не нужно создавать интерфейсы (хотя это помогло бы тестировать. Представить интерфейс позже - это простой рефакторинг в таких языках, как Java). Я просто снимаю ответственность за создание с пользователя класса.

Самой большой ценой в моей голове было бы изменение мнения. Чтобы научиться думать DI. Преимущества включают более легкое тестирование. Разделение концерна и многое другое.

Answer 2

Проще говоря, выполнение объектно-ориентированной разработки без внедрения зависимостей - это плохо. Очень плохой. Внедрение зависимостей, на мой взгляд, является корнем хорошо понятной разработки ОО: разделение проблем, слабая связь между независимыми компонентами, кодирование в слоях, все это делается с помощью DI. Кроме того, это делает тестирование невероятно простым и позволяет использовать такие методы, как TDD, mocking (BDD) и т. Д.

Как сказал Шакьямуни в своем ответе, DI - это не основа, которую вы используете. Spring не изобрел DI, он просто предлагает решение для его достижения. Так что, если ваш первоначальный вопрос «мы должны использовать Spring», то я бы сказал, что это вопрос личного вкуса. Вы можете достичь точно такого же результата, если сделаете это сами. Я работал в проекте с контейнерами или без них (Spring, Pico и т. Д.), И все они имеют свои преимущества и недостатки. Тем не менее, я предпочитаю не использовать его и самостоятельно управлять своим DI.

Это DI:

// constructor
public MyClass(MyDependencyInterface injected) {
    this.dependency = injected;
}

или что:

// setter injection
public void setDependency(MyDependencyInterface injected) {
    this.dependency = injected;
}

И я надеюсь, что DI не станет проблемой производительности из-за рефлексии.

Понятия не имею, что вы подразумеваете под этим. DI не требует отражения.

Answer 3

Основная проблема в Java состоит в том, что когда вы в классе A делаете new B(), это означает, что класс A очень тесно связан с классом B на уровне байтового кода.

Как правило, это хорошая вещьпоскольку это означает, что получающееся в результате приложение становится очень устойчивым, так как все «кирпичики» очень хорошо «склеены».

Однако вам часто приходится откладывать некоторые проблемы проектирования для развертывания времени (а иногда даже времени выполнения)и способ обработки этого в Java традиционно состоял в том, чтобы делегировать Фабрику, которая, возможно, даже в свою очередь делегирует другую Фабрику и т. д., пока вы не достигнете места, где вы принимаете решение.Обычно это делается с помощью файла свойств, содержащего либо флаги, соответствующие if -словиям в коде (что требует от программиста предвидеть все ситуации при написании кода), либо имена классов, которые необходимо разрешить с помощью Class.forName() (что является хрупким каккомпилятор не может помочь).

Преимущество Dependency Injection заключается в том, что вы обойдете жесткую привязку оператора new, делегировав ответственность за создание соответствующего объекта вне вашего собственного кода (для контейнера, но это можета также быть божеством).Вы создаете несколько очень четких линий, в которых вы можете собрать все вместе, и для тех DI-платформ, обеспечивающих настройку кода (как Guice), результат может быть как устойчивым, так и модульным.

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

Answer 4

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

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

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