Технический термин для обозначения противоположности внедрения зависимости?

Это скорее номенклатура (техническое письмо), а не чисто технический вопрос. Я пытаюсь написать предложение по рефакторингу (и назначить его себе), сосредоточенное на расширении внедрения зависимостей в нашем приложении. Хотя мы используем Spring для автоматического подключения bean-компонентов, все еще существуют экземпляры, использующие экземпляры bean-компонентов MyClass obj = new MyClass(...), которые могут быть полностью внедрены. Я хотел бы, чтобы мое предложение использовало элегантную номенклатуру и ссылалось на шаблон проектирования напротив DI с подходящим термином.

Является ли «тесная связь» адекватным термином, который выступает как антоним DI?

Нет. Тесная связь - это гораздо больше, чем то, с чем имеет дело внедрение зависимостей.

Внедрение зависимостей экстернализует решение о реализации. Это имеет большое значение для разъединения, но связь - это не только это.

Хороший антоним для внедрения зависимости - это жесткое кодирование зависимости . Когда вы создаете (используете new или непосредственно используете какую-то фабрику) внутри объекта поведения, вы смешали две разные проблемы. Сервисный локатор помогает отделить, но оставляет вас связанным с самим сервисным локатором.

Сцепление - это больше, чем просто разделение конструкции и поведения. Если у меня есть 101 метод, который нужно вызывать в определенном порядке от класса A до класса B, я тесно связан. Не имеет значения, насколько чудесно разделены конструкция и поведение.

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

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

[Нежелательная] связь, хотя и не совсем ортогональная, может либо возникнуть, либо быть смягчена в любом случае. Они оба связаны с DependencyClass:

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

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

DependencyLookupConstructorсвязан с конкретным DependencyClassв этом случае. Но они оба связаны с 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()- или как угодно. Мой код может запрашивать, что ему нужно функционально, даже не зная, какие интерфейсы он поддерживает.}

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

Я бы пошел с инкапсуляцией зависимостей . Это выражает зависимость заблокирована, а не посещать и снова уйти.