Технічний термін для позначення протилежної ін'єкції залежності?

Це скоріше номенклатура (технічне написання), а не суто технічне питання. Я намагаюся написати пропозицію щодо рефакторингу (і присвоїти це собі), зосереджена на розширенні ін'єкції залежності у нашій програмі. У той час як ми використовуємо Spring для автоматичного з'єднання бобів, все ще є випадки, коли інстанціюють боби MyClass obj = new MyClass(...), які можна повністю вводити. Я хотів би зробити свою пропозицію використовувати елегантну номенклатуру та посилатись на модель дизайну, протилежну DI, з відповідним терміном.

Чи є "щільне з'єднання" адекватним терміном, який виступає як антонім до DI?

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

Ін'єкційна залежність екстерналізує рішення про реалізацію. Це дуже довго розв'язується, але зчеплення - це не просто це.

Хорошим антонімом для введення залежності є важке кодування залежності . Коли ви конструюєте (використовуєте новий або безпосередньо використовуєте якусь фабрику) всередині об'єкта поведінки, ви разом розбили дві різні проблеми. Локатор сервісу допомагає роз’єднати, але залишає вас в поєднанні з самим локатором служби.

З'єднання - це більше, ніж просто розділення конструкції та поведінки. Якщо у мене є 101 метод, який потрібно викликати в якомусь конкретному порядку від класу А до класу В, я міцно поєднаний. Не має значення, наскільки чудово розділені конструкція та поведінка.

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

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

[Небажане] з'єднання, хоча і не зовсім ортогональне питання, може виникати або пом'якшуватися будь-яким способом. Вони поєднані з DependencyClass:

public DependencyInjectedConstructor(DependencyClass dep) {
  dep.do();
}

public DependencyLookupConstructor() {
  var dep = new DependencyClass();
  dep.do();
}

DependencyLookupConstructorDependencyClassв цьому випадку пов'язане з певним . Але вони обоє поєднані DependencyClass. Справжнє зло, якщо воно є тут, не є обов'язково з'єднанням, це DependencyLookupConstructorпотрібно змінити, якщо DependencyClassраптом потрібні власні залежності, які вводяться ¹ .

Однак цей конструктор / клас ще більш вільно поєднаний:

public DependencyLocatingConstructor() {
  var dep = ServiceLocator.GetMyDoer();
  dep.do();
}

Якщо ви працюєте в C #, вищевикладене дозволить вам ServiceLocatorповернути що- небудь після GetMyDoer()виклику, доки він може, do()що DependencyLocatingConstructorмає do(). Ви отримуєте перевагу перевірки підпису під час компіляції, навіть не підключаючись до повного інтерфейсу ² .

Отже, виберіть свою отруту.

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

• Шаблон локатора обслуговування
• Локатор залежності / Місцезнаходження
• Побудова прямого об'єкта / залежності
• Прихована залежність
• "Не введення залежності"

^{1. За іронією долі, деякі проблеми, які DI вирішує на більш високих рівнях, є свого роду результатом [перевитрати] використання DI на нижчих рівнях. Я мав задоволення працювати над з непотрібною базою коди складності в усьому , як у результаті розміщення жменьки місць , де ця складність на насправді допомогла ... Я правда упередженого поганому вплив.}

^{2. Використання розташування служби також дозволяє вам легко вказати різні залежності одного типу за їх функціональною роллю від коду виклику , при цьому, як і раніше, значною мірою сприймає спосіб побудови залежності. Припустимо, вам потрібно вирішити Userабо IUserдля різних цілей: Наприклад, Locator.GetAdministrator()проти Locator.GetAuthor()- або будь-якої іншої . Мій код може запитати те, що йому потрібно функціонально, навіть не знаючи, які інтерфейси він підтримує.}

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

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