Это скорее номенклатура (техническое письмо), а не чисто технический вопрос. Я пытаюсь написать предложение по рефакторингу (и назначить его себе), сосредоточенное на расширении внедрения зависимостей в нашем приложении. Хотя мы используем Spring для автоматического подключения bean-компонентов, все еще существуют экземпляры, использующие экземпляры bean-компонентов MyClass obj = new MyClass(...)
, которые могут быть полностью внедрены. Я хотел бы, чтобы мое предложение использовало элегантную номенклатуру и ссылалось на шаблон проектирования напротив DI с подходящим термином.
Является ли «тесная связь» адекватным термином, который выступает как антоним DI?
terminology
refactoring
dependency-injection
amphibient
источник
источник
Ответы:
Нет. Тесная связь - это гораздо больше, чем то, с чем имеет дело внедрение зависимостей.
Внедрение зависимостей экстернализует решение о реализации. Это имеет большое значение для разъединения, но связь - это не только это.
Хороший антоним для внедрения зависимости - это жесткое кодирование зависимости . Когда вы создаете (используете new или непосредственно используете какую-то фабрику) внутри объекта поведения, вы смешали две разные проблемы. Сервисный локатор помогает отделить, но оставляет вас связанным с самим сервисным локатором.
Сцепление - это больше, чем просто разделение конструкции и поведения. Если у меня есть 101 метод, который нужно вызывать в определенном порядке от класса A до класса B, я тесно связан. Не имеет значения, насколько чудесно разделены конструкция и поведение.
Связь является мерой взаимозависимости двух объектов. Все, что затрудняет внесение изменений в одно без влияния на другое, способствует соединению. Внедрение зависимости помогает в этом, но это еще не все.
источник
N
нескольких часов ... Или до тех пор, пока не будет выбран ответ. Я знаю, что я не совсем объективен, когда один ответ уже имеет 10 голосов, а остальные 5 не имеют ни одного!Строго говоря, внедрение зависимостей только противостоит НЕ внедрению зависимостей - и, следовательно, любой стратегии управления зависимостями, которая не является внедрением зависимостей.
[Нежелательная] связь, хотя и не совсем ортогональная, может либо возникнуть, либо быть смягчена в любом случае. Они оба связаны с
DependencyClass
:DependencyLookupConstructor
связан с конкретнымDependencyClass
в этом случае. Но они оба связаны сDependencyClass
. Настоящее зло, если оно есть, не обязательно связано, это то, чтоDependencyLookupConstructor
нужно изменить, еслиDependencyClass
внезапно понадобятся свои собственные зависимости 1 .Однако этот конструктор / класс еще более слабо связан:
Если вы работаете в C #, вышеприведенное позволит вам
ServiceLocator
возвращать что-либо приGetMyDoer()
вызове, если оно имеетdo()
то, чтоDependencyLocatingConstructor
имеетdo()
. Вы получаете преимущество проверки подписи во время компиляции, даже не будучи подключенным к полному интерфейсу 2 .Итак, выбери свой яд.
Но в принципе, если есть конкретная «противоположность» внедрения зависимостей, это будет нечто другое в сфере «стратегий управления зависимостями». Среди прочего, если бы вы использовали в разговоре что-либо из перечисленного ниже, я бы узнал, что это НЕ внедрение зависимости:
1. Как ни странно, некоторые из проблем, которые DI решает на более высоких уровнях, являются своего рода результатом [чрезмерного] использования DI на более низких уровнях. Я имел удовольствие работать над кодовыми базами с ненужной сложностью повсюду в результате приспособления к горстке мест, где эта сложность действительно помогла ... По общему признанию, я предвзятый из-за плохой экспозиции.
2. Использование местоположения услуг позволяет также легко определить различные зависимости одного и того же типа, их функциональной роли из кода вызывающего , в то же время в значительной степени агностик о том , как строится зависимость. Предположим, вам нужно решить
User
илиIUser
для разных целей: например,Locator.GetAdministrator()
противLocator.GetAuthor()
- или как угодно. Мой код может запрашивать, что ему нужно функционально, даже не зная, какие интерфейсы он поддерживает.источник
DependencyInjectedConstructor(DependencyClass dep)
заключается в том, что DependencyClass может быть интерфейсом или абстрактным классом. Вот почему меня огорчает, что кодеры C # используют префикс интерфейса, как вIDependency
. Как клиент, это действительно не мое дело, что это за Зависимость. Пока я не создаю это, все, что я должен знать, - как говорить с этим. Что это, это чужая проблема.DependencyClass
быть абстрактным интерфейсом на всех. Требуется только, чтобы логика построения / конфигурации / размещения существовала «где-то еще». ... Ну, и, что более важно, вопрос в том, что DI не является "противоположностью жесткой связи" :)dynamic
параметры. (Но неvar
параметры, если память служит.) Так что, с DI в C #, я думаю , что я должен либо кодировать интерфейс, либо я должен полностью отказаться от проверки во время компиляции.dynamic
илиvar
получение объекта из локатора позволяет игнорировать интерфейс и использовать любой класс, который можетdo()
вам нужен, независимо от того, реализует ли этот класс какой-либоIDoer
интерфейс. Другими словами, если у нас A-> B <-C, DI отделяет A от C, но требует, чтобы A и C были связаны с B, и предотвращает использование D, даже если D будетdo()
.Я не знаю , что есть конкретный, широко распространенная терминология промышленности, но альтернативные варианты , которые приходят на ум , включают в себя внутреннее создание экземпляра , создание внутренних зависимостей , локальные зависимости , или локально контекстные зависимости .
источник
instance creation
но это не достаточно конкретно. DI создает экземпляры, но с помощью контроллера, а не на уровне приложения. возможноinternal instance creation
Я бы пошел с инкапсуляцией зависимостей . Это выражает зависимость заблокирована, а не посещать и снова уйти.
источник