Чи є докази того, що використання ін'єкцій залежностей покращує результати в розробці програмного забезпечення?

Незважаючи на його популярність, чи є якісь емпіричні докази, які показують, що залежність від ін'єкцій (та / або використання контейнера DI) допомагає, скажімо, зменшити кількість помилок, покращити ремонтопридатність або збільшити швидкість розвитку програмних програм у реальному житті?

TLDR

Емпіричні дані не мають значення. Інструменти та практика (як DI) вирішують конкретні проблеми. Зрозумійте свої проблеми, навчіться користуватися інструментами, і це стане очевидним, коли інструмент цінний - і ви зможете пояснити результати набагато пророчіше, ніж будь-які узагальнені, узагальнені, емпіричні дані.

А тепер, з набагато більшою багатослівністю ...

Чи є емпіричні докази?

Звичайно, певно. Або хоча б можливо. Але, кого це хвилює? Це не актуально.

Статистичний аналіз вартості та вигоди ІР може бути цікавим з точки зору наукової діяльності, але він не обов'язково передбачає індивідуальний успіх. Сукупні результати приховують окремі успіхи та невдачі. І я можу стверджувати, що дані щодо "євангельських" практик є особливо отруйними. Ці дисципліни, як правило, приваблюють як завзятих, так і дурнів, що обоє затьмарюють чистий вплив "чистої" реалізації, і будь -який з них ви можете бути!

Отже, як ми знаємо, що ін'єкція залежності залежить від цінності ?

Гарне питання! ВЕЛИКИЙ питання, насправді. І я з вами - ненавиджу витрачати час і душевні зусилля на догматичні "найкращі практики", які ніхто не може виправдати. Отже, я радий, що ти запитав.

Ага. Але, ось проблема, яка бентежить ... Загалом , ви цього не знаєте. І, що ще більше бентежить, ваш код може насправді нічим не покращитись, запровадивши DI.

GASP!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...

Отже, можливо, зараз вам цікаво ...

Чому я повинен турбуватися, "що речі не були доведені ер-нутін!"

Перш за все, давайте всі - з кожної сторони дебатів - просто влаштуємось. Я можу вас запевнити, що між догматизмом і скептицизмом лежить прекрасний рай розуму та безтурботності. (І випадковий ексцентричний пост SE.SE.) І, POAP може привести вас туди.

... Під яким я маю на увазі Принцип застосування Принципів :

Принципи, зразки та практики не є кінцевою метою. Отже, правильне та правильне застосування кожного надихається та обмежується вищою, більш кінцевою метою.

Вам потрібно зрозуміти, чому ви робите те, що робите!

(POAP не звільняється від POAP.)

^{(Я б сказав, "акцент мій", але це все одно з мого власного "блогу". Отже, це все моє!)}

Дозвольте мені ще раз зазначити головний момент: Вам потрібно зрозуміти, чому ви робите те, що робите.

І, можливо, для уточнення, зазвичай не має сенсу брати якесь дане "щось" (наприклад, введення залежностей), і використовувати його, не розуміючи, яку проблему він вирішує - конкретно для вас. Якщо ви розумієте свої проблеми і як працює "щось" (як DI), буде дещо "очевидно", наскільки корисне "щось", дуже незалежно від того, що підказує узагальнені, узагальнені, емпіричні дані.

Якщо корисність DI або ООН -helpfulness вам не очевидно , - або , по крайней мере , за межами ваших міркувань повноважень - ви або не розумієте , DI, чи ви не розумієте , ваші власні проблем.

Розглянемо реальну "притчу".

Нам потрібно побудувати коробку. У нас є дрова. У нас цвяхи. І, у нас є два інструменти: стандартний кінцевий молоток і викрутка .

Тепер ми можемо мати кілька широких емпіричних даних, які свідчать про те, що коробки, побудовані за допомогою викруток, є значно більш міцними коробками в цілому, порівняно з коробками з молотками. Але, якщо ви спробуєте вкрутити ці цвяхи, у вас взагалі не вийде коробка. І якщо ви спробуєте вдарити їх за допомогою викрутки, ви, зрештою, зможете їх запустити; але це зажадає значно більше часу та зусиль, і кінцевий результат буде менш точним (і надійним), ніж ви просто використовували молоток.

І якщо ви коли-небудь бачили, щоб хтось використовував будь-який інструмент раніше, і якщо ви розумієте, як виглядає коробка, рішення очевидно.

Телекінез!

Помилка ... хм ...

Так, яка проблема вирішує впорскування залежностей?

Він працює на запобігання жорсткого неконфігуруваного коду, який часто не може бути перевірений .

Це робиться, дозволяючи викликати код для вирішення, з якими об'єктами працює модуль. І я знаю, що ти це думаєш, і ти маєш рацію: це навіть не зовсім нова концепція. Параметри методу / функції існують з моменту виникнення алгебри.

Ми почали евангелізувати передачу основного параметра, називаючи його "Введення залежностей", як тільки ми накопичили і успадкували достатньо коду, щоб побачити наші дисбаланси. Гори коду, за яким ми сиділи на вершині, неможливо було легко змінити, протестувати або навіть повторно використати просто тому, що залежності були приховані.

Отже, ревний хрестовий похід для ін'єкцій залежностей ...

К. Але я можу передати аргументи просто чудово. Чому каркаси ?

Як я розумію, рамки DI в першу чергу вирішують проблему нарощування котлоагрегатів (через надмірний DI, IMO) - особливо, коли для всіх модулів, які їх вимагають, існують стандартні залежності "за замовчуванням". Рамки DI роблять магічні (потенційно навіть пустотливі!) Речі, щоб проскочити ті залежності за замовчуванням, коли вони явно не передаються в точці виклику. (Той же ефект, що і Локатор послуг, коли використовується таким чином, пам’ятайте!)

Введення залежності в якості "дисципліни" насправді важко поправити. Справа не в тому, використовувати DI чи ні; справа в тому, щоб знати, які залежності можуть змінитись або потребуватимуть глузування та введення їх . І тоді, вирішувати, чи підходить DI краще, ніж якась альтернатива, як-от Місце розташування сервісу ...

Але, я закликаю вас до нагугліть , може побачити цей SO відповідь , можливо , поговорити з супер-дослідний і успішний розробник у вашій галузі, і розмістити приклади конкретних для CR.SE .

Я шукав Google, Google Scholar, ACM та IEEE. Ось документи, які я зміг знайти:

• Рамки ін'єкційних залежностей: поліпшення до встановленості? . Він стверджує, що "перевіряемость" можна визначити як "низьку згуртованість". У ньому зазначається, що DI призводить до зниження згуртованості, нижча згуртованість співвідноситься з більш високим покриттям випробувань, а також, що більш високе покриття випробувань корелює з виявленням більшої кількості несправностей. У ньому йдеться про те, що, виходячи з цього, DI покращує доказливість.

  Мені це не подобається з кількох причин. Перш за все, це говорить «A корелює з B, B співвідноситься з C, тому A викликає C», що є декількома кроками в логіці, яку я не вважаю добре підтримуваною папером. По-друге, він визнає, що це лише вимірювання "підрозділів довіреності", і що "заповітність" взагалі не є чимось легко визначити. Нарешті, їх міра доказовості визначається за кількістю введених залежностей!

• Вплив ін'єкції залежності на ремонтопридатність . Вони порівнюють проекти, що використовують DI, та проекти, які не використовують DI, вони знайшли на SourceForge, і бачать, чи є якісь відмінності в показниках згуртованості. Щоб зменшити упередженість, вони з'єднали проекти, щоб вони були максимально схожими. Зрештою, вони побачили сигнали про те, що проекти з великою кількістю DI були дещо менш сполученими, ніж проекти з лише невеликим DI. Однак, схоже, не було суттєвої різниці в згуртованості між проектами DI та їхньою парою, що не стосується DI, тому це може бути наслідком конкретних областей. Вони перераховують "відсутність кореляції" як основний результат, і "можливо, це трохи допомагає?" як тема для подальшого вивчення.

• Емпірична оцінка впливу введення залежностей на розробку програм веб-служб . Реферат насправді не пояснює, що вони шукають. Я викопав і прочитав переддрук, і наскільки я можу сказати, це насправді про те, наскільки добре автоматизовані інструменти можуть виявити послуги. Послуги, написані в стилі DI, були легше відкриті. Крім того, воно цитує попереднє дослідження, яке я перераховував, як надання емпіричних доказів того, що DI зменшує з'єднання, що є протилежним тому, що заявляв цей документ.

За цими трьома статтями (а також за Емпіричним дослідженням використання ін'єкційних залежностей на Яві , яке стосується лише виявлення) я проаналізував усі статті, які цитували їх, жодна з яких не стосувалася визначення ефективності DI. Враховуючи все це, я впевнено кажу, що ні , ми ще не маємо емпіричних доказів щодо того, покращує чи не DI якість програмного забезпечення.