Критика та недоліки ін'єкції залежності

Ін'єкційна залежність (DI) - добре відома та модна модель. Більшість інженерів знають його переваги, як-от:

• Можливість / простота ізоляції при тестуванні одиниць
• Явно визначають залежності класу
• Сприяння гарному дизайну (наприклад, принцип єдиної відповідальності (SRP))
• Увімкнення швидкого переключення реалізацій ( DbLoggerзамість ConsoleLoggerнаприклад)

Я вважаю, що існує загальна думка про галузь, що DI - це корисна модель. Наразі критики не надто багато. Недоліки, про які йдеться у громаді, зазвичай незначні. Дехто з них:

• Збільшена кількість занять
• Створення непотрібних інтерфейсів

В даний час ми обговорюємо дизайн архітектури з моїм колегою. Він досить консервативний, але відкритий. Йому подобається ставити під сумніви речі, які я вважаю гарними, тому що багато людей в ІТ просто копіюють новітні тренди, повторюють переваги і взагалі не думають занадто багато - не аналізуйте занадто глибоко.

Я хотів би запитати:

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

По-перше, я хотів би відокремити підхід дизайну від концепції каркасів. Введення залежності в найпростіший і найосновніший рівень просто:

Батьківський об'єкт забезпечує всі залежності, необхідні для дочірнього об'єкта.

Це воно. Зауважте, що для цього нічого не потрібно інтерфейсів, фреймворків, будь-якого стилю введення тощо. Для справедливості я вперше дізнався про цю модель 20 років тому. Це не нове.

Через більш ніж 2 людей, які мають плутанину щодо терміну батько та дитина, в контексті введення залежності:

• Батьківським є об'єкт , який створює і налаштовує дочірній об'єкт він використовує
• Дитина є компонентом , який призначений для пасивного примірника. Тобто він призначений для використання будь-яких залежностей, передбачених батьком, і не створює власних залежностей.

Ін'єкційна залежність є схемою для складу об'єкта .

Чому інтерфейси?

Інтерфейси - це договір. Вони існують для обмеження того, наскільки щільно пов'язані два об'єкти. Не кожній залежності потрібен інтерфейс, але вони допомагають писати модульний код.

Коли ви додаєте в концепцію тестування одиниць, у вас може бути дві концептуальні реалізації для будь-якого інтерфейсу: реальний об'єкт, який ви хочете використовувати у вашій програмі, та знурений або стертий об'єкт, який ви використовуєте для тестування коду, який залежить від об'єкта. Це одне може бути достатньо виправданням для інтерфейсу.

Чому рамки?

По суті, ініціалізація та надання залежностей до дочірніх об'єктів може бути непростим, коли їх існує велика кількість. Рамки забезпечують такі переваги:

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

Вони також мають такі недоліки:

• Батьківський об'єкт - це "контейнер", а не що-небудь у вашому коді
• Це ускладнює тестування, якщо ви не можете вказати залежності безпосередньо у своєму тестовому коді
• Це може уповільнити ініціалізацію, оскільки вона вирішує всі залежності за допомогою рефлексії та багатьох інших хитрощів
• Налагодження під час виконання може бути складнішим, особливо якщо контейнер вводить проксі між інтерфейсом і фактичним компонентом, що реалізує інтерфейс (на думку приходить програмоване орієнтоване вбудоване в Spring). Контейнер - це чорна скринька, і вони не завжди побудовані з будь-якою концепцією полегшення процесу налагодження.

Все, що говорили, є компроміси. Для невеликих проектів, де не так багато рухомих деталей, і мало підстав використовувати рамку DI. Однак для складніших проектів, де вже створені певні компоненти, рамки можуть бути виправдані.

А як щодо [випадкової статті в Інтернеті]?

Що з цим? Багато разів люди можуть завищуватись і додавати купу обмежень і лаяти вас, якщо ви не робите речі "єдиним правдивим способом". Існує не один вірний спосіб. Подивіться, чи можете витягти із статті щось корисне і проігнорувати речі, з якими ви не згодні.

Словом, подумайте самі і спробуйте все.

Робота зі "старими головами"

Вчіться стільки, скільки зможете. Що ви знайдете з багатьма розробниками, які працюють у свої 70-ті, - це те, що вони навчилися не бути догматичними щодо багатьох речей. У них є методи, з якими вони працювали десятиліттями, які дають правильні результати.

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

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

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

Розглянемо модуль, який завантажує деякі дані із зовнішньої служби, аналізує їх та виконує складний аналіз та записує результат у файл.

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

Але набагато кращим рішенням є просто відокремити аналіз від введення / виводу. Якщо аналіз буде вилучений в модуль без побічних ефектів, це буде набагато простіше перевірити. Зауважте, що глузування - це кодовий запах - цього не завжди можна уникнути, але загалом, краще, якщо ви можете протестувати, не покладаючись на глузування. Таким чином, усуваючи залежності, ви уникаєте проблем, які DI повинен усунути. Зауважте, що така конструкція також набагато краще дотримується SRP.

Хочу підкреслити, що DI не обов'язково полегшує SRP або інші хороші принципи проектування, такі як розділення проблем, висока згуртованість / низька зв'язок тощо. Це може також мати протилежний ефект. Розглянемо клас A, який використовує інший клас B внутрішньо. B використовується тільки A і тому повністю інкапсульований і може вважатися деталлю реалізації. Якщо ви зміните це, щоб ввести B в конструктор A, то ви відкрили цю детальну інформацію про реалізацію, і тепер знання про цю залежність і про те, як ініціалізувати B, термін експлуатації B і так далі повинні існувати в іншому місці в системі окремо від А. Отже, у вас загалом гірша архітектура з протікаючими проблемами.

З іншого боку, є деякі випадки, коли DI справді корисні. Наприклад, для глобальних служб з побічними ефектами, такими як реєстратор.

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

Частина вашого запитання зводиться до: "Чи слід створювати зайві інтерфейси, щоб задовольнити вимоги шаблону?" Ви, напевно, вже усвідомлюєте відповідь на це - абсолютно ні ! Кожен, хто каже вам інакше, намагається продати вам щось - швидше за все, дорогі консультаційні години. Інтерфейс має значення лише в тому випадку, якщо він представляє абстракцію. Інтерфейс, який просто імітує поверхню одного класу, називається "інтерфейсом заголовка", і це відомий антипатерн.

На мій досвід, існує ряд недоліків ін'єкції залежності.

По-перше, використання DI не спрощує автоматичне тестування настільки, наскільки рекламується. Блок тестування класу з макетною реалізацією інтерфейсу дозволяє перевірити, як цей клас буде взаємодіяти з інтерфейсом. Тобто це дозволяє вам перевірити, як тестуваний клас використовує контракт, наданий інтерфейсом. Однак це забезпечує набагато більшу впевненість, що вхід з тестуваного класу в інтерфейс є таким, як очікувалося. Це дає досить низьку впевненість, що тестовий клас відповідає, як очікується, на вихід з інтерфейсу, оскільки це майже універсальний макетний вихід, який сам піддається помилкам, надмірним спрощенням тощо. Коротше кажучи, воно НЕ дозволяє вам перевірити, що клас буде вести себе так, як очікувалося, при реальній реалізації інтерфейсу.

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

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

Я дотримувався поради Марка Семана з "Ін'єкції залежності в .NET" - щоб припустити.

DI слід застосовувати, коли у вас є "мінлива залежність", наприклад, є обґрунтований шанс, що він може змінитися.

Тож якщо ви думаєте, що у майбутньому у вас може бути більше однієї реалізації, або реалізація може змінитися, використовуйте DI. Інакше newце добре.

Про мого найбільшого домашнього улюбленця про ДІ вже згадувалось у кількох відповідях, але я трохи розгорнуся тут. DI (як це в основному робиться сьогодні, з контейнерами і т. Д.) Дійсно, ДУЖЕ шкодить читабельності коду. І читабельність коду, мабуть, є причиною більшості сучасних нововведень програмування. Як хтось сказав - писати код легко. Читання коду важко. Але це також надзвичайно важливо, якщо ви не пишете якусь крихітну утиліту одноразового виписування.

Проблема щодо DI в цьому плані полягає в тому, що він непрозорий. Контейнер - це чорний ящик. Об'єкти просто з'являються звідкись, і ви поняття не маєте - хто їх сконструював і коли? Що було передано конструктору? З ким я ділюся цим випадком? Хто знає...

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

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

Увімкнення швидкого переключення реалізацій (наприклад, DbLogger замість ConsoleLogger)

Хоча DI в цілому, безумовно, хороша річ, я б радив не використовувати його наосліп для всього. Наприклад, я ніколи не ввожу реєстратори. Однією з переваг DI є створення явних і зрозумілих залежностей. Немає сенсу називати ILoggerзалежність майже кожного класу - це просто захаращення. Це відповідальність лесоруба забезпечити необхідну гнучкість. Усі мої реєстратори є статичними кінцевими членами, я можу розглянути можливість введення лісоруба, коли мені потрібен нестатичний.

Збільшена кількість занять

Це є недоліком даної рамки DI або глузуючої рамки, а не самого DI. У більшості місць мої класи залежать від конкретних класів, це означає, що нульова плита котла потрібна. Guice (рамка Java DI) прив'язує клас за замовчуванням до себе, і мені потрібно лише переосмислити прив'язку в тестах (або провести їх замість них вручну).

Створення непотрібних інтерфейсів

Я створюю інтерфейси лише тоді, коли це потрібно (що досить рідко). Це означає, що іноді мені доводиться замінювати всі входження класу інтерфейсом, але IDE може це зробити для мене.

Чи слід використовувати ін'єкцію залежності, коли ми маємо лише одну реалізацію?

Так, але уникайте будь-яких доданих котельних плит .

Чи слід забороняти створювати нові об'єкти, окрім мовних / рамкових?

Ні. Буде багато класів цінностей (незмінних) та даних (змінних), де екземпляри просто створюються та передаються навколо, і де немає сенсу їх вводити, оскільки вони ніколи не зберігаються в іншому об'єкті (або лише в інших таких об’єктів).

Для них вам може знадобитися ввести фабрику замість цього, але більшу частину часу це не має сенсу (уявіть, наприклад, @Value class NamedUrl {private final String name; private final URL url;}вам тут дійсно не потрібна фабрика і нічого не потрібно вводити).

Чи є введення однієї реалізації поганою ідеєю (скажімо, у нас є лише одна реалізація, тому ми не хочемо створювати "порожній" інтерфейс), якщо ми не плануємо одиничне тестування певного класу?

IMHO це добре до тих пір, поки він не викликає розшарування коду. Не вводьте залежність, але не створюйте інтерфейс (і не шалений конфігураційний XML!), Як це можна зробити пізніше без зайвих клопотів.

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

Ще одним недоліком більшості фреймворків DI є накладні витрати. Це можна перенести на час компіляції (для Java, є Dagger , про інші мови немає).

Ще одним недоліком є ​​магія, що відбувається скрізь, яку можна налаштувати (наприклад, я відключив створення проксі під час використання Guice).

Я мушу сказати, що, на мою думку, все поняття ін'єкції залежності є завищеним.

DI - сучасний еквівалент глобальних цінностей. Речі, які ви вводите, - це глобальні сингтони та чисті кодові об'єкти, інакше ви не можете їх вставити. Більшість застосувань DI вимушені вам використовувати для використання певної бібліотеки (JPA, Spring Data тощо). Здебільшого, DI забезпечує ідеальне середовище для вирощування та вирощування спагетті.

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

Тоді ви створюєте екземпляр класу Test і випробовуєте всі його методи. Деяким із вас це не буде зрозуміло - методи, які ви протестуєте, належать до тестуваного класу. І всі ці випробування методів відбуваються в одному файлі класу - одиничному класі тестування, пов'язаному з тестуваним класом. Тут нульові накладні витрати - ось як працює тестування одиниць.

У коді ця концепція виглядає приблизно так ...

class ClassUnderTest {

   protected final ADependency;
   protected final AnotherDependency;

   // Call from a factory or use an initializer 
   public void initializeDependencies() {
      aDependency = new ADependency();
      anotherDependency = new AnotherDependency();
   }
}

class TestClassUnderTest extends ClassUnderTest {

    @Override
    public void initializeDependencies() {
      aDependency = new MockitoObject();
      anotherDependency = new MockitoObject();
    }

    // Unit tests go here...
    // Unit tests call base class methods
}

Результат точно рівносильний використанню DI - тобто ClassUnderTest налаштований для тестування.

Єдині відмінності полягають у тому, що цей код абсолютно стислий, повністю інкапсульований, простіше кодувати, простіше зрозуміти, швидше, використовує менше пам'яті, не вимагає альтернативної конфігурації, не вимагає ніяких фреймворків, ніколи не стане причиною 4 сторінки (WTF!) Слід стека, який включає саме ZERO (0) класи, які ви написали, і цілком очевидний для всіх, хто має навіть найменші знання про ОО, від початківця до Гуру (ви могли б подумати, але помилитесь).

Це, звичайно, ми не можемо використати - це занадто очевидно і недостатньо модно.

Зрештою, найбільша стурбованість щодо DI полягає в тому, що проекти, які я бачив, зазнають невдач, всі вони були масивними кодовими базами, де DI був клеєм, який тримав все разом. DI не є архітектурою - він дійсно доречний лише у кількох ситуаціях, більшість з яких вимушені вам використовувати іншу бібліотеку (JPA, Spring Data тощо). Здебільшого, у добре розробленій кодовій базі більшість використання DI відбуватиметься на рівні нижче, ніж відбувається ваша щоденна діяльність з розробки.

Дійсно ваше запитання зводиться до "Чи погано тестування приладу?"

99% ваших альтернативних класів для ін'єкції будуть макетами, які дозволять перевірити одиницю.

Якщо ви зробите тестування одиниць без DI, у вас виникає проблема, як змусити класи використовувати знурені дані або глузливий сервіс. Скажімо, «частина логіки», оскільки ви, можливо, не розділяєте її на сервіси.

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

Важко уявити недолік настільки погано, що перевага одиничного тестування завищена.