Termin techniczny oznaczający przeciwieństwo wstrzykiwania zależności?

Jest to raczej nomenklatura (pismo techniczne) niż kwestia czysto techniczna. Usiłuję napisać propozycję refaktoryzacji (i przypisać ją sobie), koncentrując się na rozszerzaniu zastrzyku zależności w naszej aplikacji. Chociaż używamy Springa do autouzupełniania fasoli, wciąż istnieją przypadki, w których instancja korzysta z fasoli MyClass obj = new MyClass(...), którą można całkowicie wstrzyknąć. Chciałbym, aby moja propozycja wykorzystywała elegancką nomenklaturę i odnosiła się do wzoru przeciwnego do DI z odpowiednim terminem.

Czy „ścisłe połączenie” jest odpowiednim terminem, który jest antonimem dla DI?

Nie. Ścisłe sprzężenie to znacznie więcej niż to, czym zajmuje się wstrzykiwanie zależności.

Wstrzyknięcie zależności uzewnętrznia decyzję o wdrożeniu. Oddzielenie tego wymaga długiej drogi, ale sprzężenie to coś więcej niż tylko to.

Dobrym antonimem dla wstrzykiwania zależności jest twarde kodowanie zależności . Kiedy konstruujesz (używasz nowej lub bezpośrednio używasz fabryki) w obiekcie zachowania, rozwiałeś dwie różne obawy. Lokalizator usług pomaga rozdzielić, ale pozostawia cię połączonym z samym lokalizatorem usług.

Sprzężenie to coś więcej niż tylko oddzielenie konstrukcji i zachowania. Jeśli mam 101 metod, które muszą być wywoływane w określonej kolejności z klasy A do klasy B, jestem ściśle powiązany. Nie ma znaczenia, jak wspaniale są rozdzielone konstrukcje i zachowania.

Sprzężenie jest miarą współzależności dwóch obiektów. Wszystko, co przyczynia się do utrudniania wprowadzania zmian w jednym bez wpływu na drugi, przyczynia się do łączenia. Zastrzyk zależności pomaga w tym, ale to nie wszystko.

Ściśle mówiąc, Wstrzykiwanie Zależności naprawdę przeciwstawia się NIE Wstrzykiwaniu Zależności - i dlatego każda strategia zarządzania zależnością, która nie jest Wstrzykiwaniem Zależności.

[Niechciane] sprzężenie, choć nie do końca ortogonalne, może wystąpić lub zostać złagodzone w obu kierunkach. Oba są powiązane z DependencyClass:

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

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

DependencyLookupConstructorDependencyClassw tym przypadku jest powiązany z konkretnym . Ale oba są połączone DependencyClass. Prawdziwe zło, jeśli jest tutaj, niekoniecznie musi być sprzężeniem, ale DependencyLookupConstructormusi się zmienić, jeśli DependencyClassnagle trzeba wprowadzić własne zależności ¹ .

Jednak ten konstruktor / klasa jest nawet bardziej luźno:

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

Jeśli pracujesz w C #, powyższe pozwoli ci ServiceLocatorzwrócić cokolwiek po GetMyDoer()wywołaniu, o ile ma to, do()co DependencyLocatingConstructorma do(). Korzyści płynące z sprawdzania poprawności podpisu w czasie kompilacji nie są nawet powiązane z pełnym interfejsem ² .

Więc wybierz swoją truciznę.

Ale w gruncie rzeczy, jeśli istnieje konkretne „przeciwieństwo” wstrzykiwania zależności, byłoby to coś innego w dziedzinie „strategii zarządzania zależnościami”. Między innymi, jeśli użyłeś któregoś z poniższych w rozmowie, rozpoznałbym to jako NIE wstrzykiwanie zależności:

• Wzorzec lokalizatora usług
• Lokalizator / lokalizacja zależności
• Bezpośrednia konstrukcja obiektu / zależności
• Ukryta zależność
• „Zastrzyk niezależny”

^{1. Jak na ironię, niektóre problemy rozwiązywane przez DI na wyższych poziomach są niejako wynikiem [nadmiernego] użycia DI na niższych poziomach. Miałem przyjemność pracować na codebases z niepotrzebnej złożoności całego wskutek umieszczenia kilka miejsc, gdzie złożoność że faktycznie pomagały ... Ja wprawdzie dociskany przez złej ekspozycji.}

^{2. Korzystanie z lokalizacji usługi umożliwia także łatwe określenie różnych zależności tego samego typu według ich roli funkcjonalnej z kodu wywołującego , przy jednoczesnym zachowaniu dużej niezależności od sposobu budowania zależności. Załóżmy, że musisz rozwiązać Userlub IUserdo różnych celów: np. Locator.GetAdministrator()Kontra Locator.GetAuthor()- lub cokolwiek innego. Mój kod może zapytać o to, czego potrzebuje funkcjonalnie, nawet nie wiedząc, jakie interfejsy obsługuje.}

Nie wiem, że istnieje specyficzny, powszechnie akceptowane terminologii przemysłu, ale alternatywy, które przychodzą na myśl to wewnętrzny tworzenie instancji , tworzenie zależności wewnętrznego , lokalne zależności lub lokalnie scoped zależnościami .

Pójdę z zależności enkapsulacji . Wyraża to, że zależność jest zamknięta, a nie odwiedzana i opuszczana ponownie.