Есть ли достоверные данные о значении Inversion of Control или внедрения зависимостей?

Question

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

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

В некоторых случаях я могу видеть, где IoC и DI помогают с имитацией, но если вы не используете Mocking или TDD, тогда какова ценность? Это случай ЯГНИ?

Answer 1

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

Во-первых, вы не используете DI (или другие принципы SOLID), потому что это помогает вам использовать TDD. И наоборот, вы делаете TDD, потому что это помогает вам в разработке - что обычно означает, что вы получаете код, который следует этим принципам.

Обсуждение причин использования интерфейсов - это другое дело, см .: https://stackoverflow.com/questions/667139/what-is-the-purpose-of-interfaces.

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

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

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

Я использую DI-фреймворк, где настройка выполняется с помощью кода. С очень маленькой конфигурацией кода вы связываете множество различных отношений. Итак, когда вы убираете обсуждение интерфейса против конкретных классов, вы на самом деле экономите печатать, а не наоборот. Также для случаев, когда конкретный класс находится в конструкторе, он подключает его автоматически (мне не нужно настраивать), создавая остальные отношения. Это также позволяет мне контролировать время жизни некоторых объектов, в частности, я могу настроить объект как Singleton, и он постоянно обрабатывает один экземпляр.

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

Итог: вам не нужно помещать все эти вызовы конструктора повсеместно, чтобы идти быстрее.

Answer 2

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

У вас все еще слабая связь, и в нескольких средах разработки вы можете представить этот интерфейс с несколькими нажатиями клавиш, если это необходимо.

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

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

Answer 3

Помимо испытаний, также стоит слабое сцепление.

Я работал над компонентами для встроенной системы Java, которая имела фиксированную конфигурацию объектов после запуска (около 50 в основном разных объектов).

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

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