Jaka jest różnica między używaniem wstrzykiwania zależności w kontenerze a używaniem lokalizatora usług?

Rozumiem, że bezpośrednie tworzenie instancji zależności w klasie jest uważane za złą praktykę. Ma to sens, ponieważ tak ścisłe łączenie wszystkiego, co z kolei sprawia, że ​​testowanie jest bardzo trudne.

Prawie wszystkie frameworki, które spotkałem, wydają się faworyzować wstrzykiwanie zależności za pomocą kontenera niż używanie lokalizatorów usług. Oba wydają się osiągać to samo, pozwalając programiście na określenie, który obiekt powinien zostać zwrócony, gdy klasa wymaga zależności.

Jaka jest różnica między nimi? Dlaczego miałbym wybierać jeden nad drugim?

Kiedy sam obiekt jest odpowiedzialny za żądanie swoich zależności, w przeciwieństwie do akceptowania ich przez konstruktor, ukrywa pewne istotne informacje. Jest tylko nieznacznie lepszy niż bardzo ściśle powiązany przypadek użycia newdo utworzenia jego zależności. Zmniejsza to sprzężenie, ponieważ w rzeczywistości można zmienić zależności, które się dostaje, ale nadal istnieje zależność, której nie można wstrząsnąć: lokalizator usług. Staje się to tym, od czego wszystko zależy.

Kontener dostarczający zależności za pomocą argumentów konstruktora zapewnia największą przejrzystość. Widzimy od razu, że obiekt potrzebuje zarówno an AccountRepository, jak i a PasswordStrengthEvaluator. Podczas korzystania z lokalizatora usług informacje te są mniej widoczne od razu. Od razu zobaczysz przypadek, w którym obiekt ma 17 zależności, i powiesz sobie: „Hmm, to wydaje się dużo. Co się tam dzieje?” Połączenia z lokalizatorem usług mogą być rozłożone na różne metody i kryć się za logiką warunkową, i możesz nie zdawać sobie sprawy, że stworzyłeś „klasę Boga” - taką, która robi wszystko. Być może ta klasa mogłaby zostać przekształcona w 3 mniejsze klasy, które są bardziej skoncentrowane, a zatem bardziej testowalne.

Teraz rozważ testowanie. Jeśli obiekt korzysta z lokalizatora usług w celu uzyskania swoich zależności, środowisko testowe będzie również potrzebowało lokalizatora usług. W teście skonfigurujesz lokalizator usług, aby dostarczał zależności do testowanego obiektu - może a FakeAccountRepositoryi a VeryForgivingPasswordStrengthEvaluator, a następnie uruchom test. Ale to więcej pracy niż określenie zależności w konstruktorze obiektu. Twoja struktura testowa staje się również zależna od lokalizatora usług. Jest to kolejna rzecz, którą musisz skonfigurować w każdym teście, co sprawia, że ​​pisanie testów jest mniej atrakcyjne.

Poszukaj „Serivce Locator to antywzór” dla artykułu Marka Seemana na ten temat. Jeśli jesteś w świecie .Net, zdobądź jego książkę. To jest bardzo dobre.

Wyobraź sobie, że jesteś pracownikiem fabryki produkującej buty .

Jesteś odpowiedzialny za składanie butów, więc będziesz potrzebować wielu rzeczy, aby to zrobić.

• Skórzany
• Miarka
• Klej
• Paznokcie
• Młot
• Nożyczki
• Sznurówki

I tak dalej.

Jesteś w pracy w fabryce i możesz zacząć. Masz listę instrukcji, jak postępować, ale nie masz jeszcze żadnych materiałów ani narzędzi.

Lokalizator usług jest jak brygadzista, który pomoże ci zdobyć to, czego potrzebujesz.

Pytasz Lokalizator usług za każdym razem, gdy czegoś potrzebujesz, a oni idą znaleźć to dla Ciebie. Lokalizator usług został wcześniej poinformowany o tym, o co prawdopodobnie poprosisz i jak go znaleźć.

Miej jednak nadzieję, że nie poprosisz o coś nieoczekiwanego. Jeśli Lokalizator nie został wcześniej poinformowany o określonym narzędziu lub materiale, nie będzie w stanie go dla ciebie zdobyć i po prostu wzrusza ramionami.

Pojemnik do wstrzykiwania zależności (DI) jest jak duże pudełko, które wypełnia się wszystkim, czego wszyscy potrzebują na początku dnia.

Gdy fabryka zostaje uruchomiona, Wielki Szef znany jako Korzeń Kompozycji chwyta pojemnik i rozdaje wszystko Kierownikom Linii .

Kierownicy liniowi mają teraz to, czego potrzebują, aby wykonywać swoje obowiązki na dany dzień. Biorą to, co mają i przekazują to, co jest potrzebne, swoim podwładnym.

Proces ten trwa, a zależności spadają na linię produkcyjną. Ostatecznie dla majstra pojawia się pojemnik z materiałami i narzędziami.

Twój brygadzista rozdaje teraz dokładnie to, czego potrzebujesz tobie i innym pracownikom, nawet o to nie pytając.

Zasadniczo, jak tylko pojawi się w pracy, wszystko, czego potrzebujesz, jest już w pudełku i czeka na Ciebie. Nie musiałeś nic wiedzieć o tym, jak je zdobyć.

Kilka dodatkowych punktów, które znalazłem podczas przeszukiwania sieci:

• Wstrzyknięcie zależności do konstruktora ułatwia zrozumienie, czego potrzebuje klasa. Nowoczesne środowiska IDE podpowiedzą, jakie argumenty przyjmuje konstruktor i jakie są ich typy. Jeśli używasz lokalizatora usług, musisz przeczytać klasę, zanim będziesz wiedział, jakie zależności są wymagane.
• Zastrzyki zależności wydają się być bardziej zgodne z zasadą „nie pytaj” niż lokalizatory usług. Nakazując, aby zależność była określonego typu, „informujesz”, które zależności są wymagane. Nie można utworzyć instancji klasy bez przekazania wymaganych zależności. W lokalizatorze usług „pytasz” o usługę, a jeśli lokalizator usług nie jest poprawnie skonfigurowany, możesz nie uzyskać wymaganej usługi.

Spóźniam się na to przyjęcie, ale nie mogę się oprzeć.

Jaka jest różnica między używaniem wstrzykiwania zależności w kontenerze a używaniem lokalizatora usług?

Czasami wcale. Różnica polega na tym, co wie o czym.

Wiesz, że używasz lokalizatora usług, gdy klient szukający zależności wie o kontenerze. Klient umiejący znaleźć swoje zależności, nawet przechodząc przez kontener w celu ich uzyskania, jest wzorcem lokalizatora usług.

Czy to oznacza, że ​​jeśli chcesz uniknąć lokalizatora usług, nie możesz użyć kontenera? Nie. Musisz tylko powstrzymać klientów przed wiedzą o kontenerze. Kluczową różnicą jest to, gdzie używasz kontenera.

Pozwala powiedzieć Clientpotrzeby Dependency. Kontener ma Dependency.

class Client { 
    Client() { 
        BeanFactory beanfactory = new ClassPathXmlApplicationContext("Beans.xml");
        this.dependency = (Dependency) beanfactory.getBean("dependency");        
    }
    Dependency dependency;
}

Właśnie zastosowaliśmy się do wzorca lokalizatora usług, ponieważ Clientwie, jak znaleźć Dependency. Jasne, że używa twardego kodu, ClassPathXmlApplicationContextale nawet jeśli wstrzykujesz, że nadal masz lokalizator usług, ponieważ Clientpołączenia beanfactory.getBean().

Aby uniknąć lokalizatora usług, nie musisz porzucać tego kontenera. Musisz go po prostu usunąć, Clientwięc Clientnie wiem o tym.

class EntryPoint { 
    public static void main(String[] args) {
        BeanFactory beanfactory = new ClassPathXmlApplicationContext("Beans.xml");
        Client client = (Client) beanfactory.getBean("client");

        client.start();
    }
}

<?xml version="1.0" encoding="UTF-8"?>
 <beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean id="dependency" class="Dependency">
    </bean>

    <bean id="client" class="Client">
        <constructor-arg value="dependency" />        
    </bean>
</beans>

Zauważ, że Clientteraz nie ma pojęcia, że ​​kontener istnieje:

class Client { 
    Client(Dependency dependency) { 

        this.dependency = dependency;        
    }
    Dependency dependency;
}

Przenieś pojemnik ze wszystkich klientów i umieść go w głównym miejscu, w którym może zbudować wykres obiektów wszystkich twoich długo żyjących obiektów. Wybierz jeden z tych obiektów do wyodrębnienia i wywołaj na nim metodę, a ty zaczniesz zaznaczanie całego wykresu.

To przenosi całą statyczną konstrukcję do XML-a kontenerów, a jednocześnie sprawia, że ​​wszyscy klienci są błogo nieświadomi, jak znaleźć ich zależności.

Ale główny nadal wie, jak zlokalizować zależności! Tak. Ale nie rozpowszechniając tej wiedzy, uniknąłeś podstawowego problemu lokalizatora usług. Decyzja o użyciu kontenera jest teraz podejmowana w jednym miejscu i można ją zmienić bez przepisywania setek klientów.

Myślę, że najłatwiejszym sposobem na zrozumienie różnicy między tymi dwoma i dlaczego kontener DI jest o wiele lepszy niż lokalizator usług, to zastanowienie się, dlaczego w pierwszej kolejności dokonujemy inwersji zależności.

Dokonujemy inwersji zależności, aby każda klasa wyraźnie określała dokładnie, od czego zależy działanie. Robimy to, ponieważ tworzy to najsłabsze sprzęgło, jakie możemy osiągnąć. Im luźniejsze sprzężenie, tym łatwiej coś przetestować i zrefaktoryzować (i generalnie wymaga to najmniej refaktoryzacji w przyszłości, ponieważ kod jest czystszy).

Spójrzmy na następującą klasę:

public class MySpecialStringWriter
{
  private readonly IOutputProvider outputProvider;
  public MySpecialFormatter(IOutputProvider outputProvider)
  {
    this.outputProvider = outputProvider;
  }

  public void OutputString(string source)
  {
    this.outputProvider.Output("This is the string that was passed: " + source);
  }
}

W tej klasie wyraźnie stwierdzamy, że potrzebujemy IOutputProvider i nic więcej, aby ta klasa działała. Jest to w pełni testowalne i zależy od jednego interfejsu. Mogę przenieść tę klasę do dowolnego miejsca w mojej aplikacji, w tym do innego projektu, a wszystko czego potrzebuje to dostęp do interfejsu IOutputProvider. Jeśli inni programiści chcą dodać coś nowego do tej klasy, co wymaga drugiej zależności, muszą wyraźnie powiedzieć, czego potrzebują w konstruktorze.

Spójrz na tę samą klasę z lokalizatorem usług:

public class MySpecialStringWriter
{
  private readonly ServiceLocator serviceLocator;
  public MySpecialFormatter(ServiceLocator serviceLocator)
  {
    this.serviceLocator = serviceLocator;
  }

  public void OutputString(string source)
  {
    this.serviceLocator.OutputProvider.Output("This is the string that was passed: " + source);
  }
}

Teraz dodałem lokalizator usług jako zależność. Oto problemy, które są od razu oczywiste:

• Pierwszym problemem jest to, że potrzeba więcej kodu, aby osiągnąć ten sam wynik. Więcej kodu jest złe. To niewiele więcej kodu, ale wciąż więcej.
• Drugi problem polega na tym, że moja zależność nie jest już wyraźna . Nadal muszę wstrzyknąć coś do klasy. Z wyjątkiem teraz rzecz, której chcę, nie jest wyraźna. Jest ukryty we właściwości rzeczy, o którą prosiłem. Teraz potrzebuję dostępu zarówno do ServiceLocator, jak i IOutputProvider, jeśli chcę przenieść klasę do innego zestawu.
• Trzeci problem polega na tym, że dodatkowa zależność może zostać przejęta przez innego programistę, który nawet nie zdaje sobie sprawy, że bierze ją, gdy dodaje kod do klasy.
• W końcu ten kod jest trudniejszy do przetestowania (nawet jeśli ServiceLocator jest interfejsem), ponieważ musimy wyśmiewać ServiceLocator i IOutputProvider zamiast tylko IOutputProvider

Dlaczego więc nie uczynić lokalizatora usług klasą statyczną? Spójrzmy:

public class MySpecialStringWriter
{
  public void OutputString(string source)
  {
    ServiceLocator.OutputProvider.Output("This is the string that was passed: " + source);
  }
}

To jest o wiele prostsze, prawda?

Źle.

Powiedzmy, że IOutputProvider jest implementowany przez bardzo długo działającą usługę internetową, która zapisuje ciąg znaków w piętnastu różnych bazach danych na całym świecie i zajmuje bardzo dużo czasu.

Spróbujmy przetestować tę klasę. Do testu potrzebujemy innej implementacji IOutputProvider. Jak piszemy test?

Aby to zrobić, musimy wykonać fantazyjną konfigurację w statycznej klasie ServiceLocator, aby użyć innej implementacji IOutputProvider, gdy jest ona wywoływana przez test. Nawet napisanie tego zdania było bolesne. Wdrożenie tego byłoby torturujące i byłoby koszmarem konserwacyjnym . Nigdy nie powinniśmy musieć modyfikować klasy specjalnie do testowania, szczególnie jeśli ta klasa nie jest klasą, którą faktycznie próbujemy przetestować.

Pozostaje Ci albo a) test, który powoduje natrętne zmiany kodu w niepowiązanej klasie ServiceLocator; lub b) brak testu. I pozostaje Ci również mniej elastyczne rozwiązanie.

Zatem klasa lokalizatora usług musi zostać wstrzyknięta do konstruktora. Co oznacza, że ​​pozostały nam konkretne problemy wspomniane wcześniej. Lokalizator usług wymaga więcej kodu, mówi innym programistom, że potrzebuje rzeczy, których nie potrzebuje, zachęca innych programistów do pisania gorszego kodu i daje nam mniejszą elastyczność w posuwaniu się naprzód.

Mówiąc prosto , lokalizatory usług zwiększają sprzężenie w aplikacji i zachęcają innych programistów do pisania wysoce sprzężonego kodu .