Jakie są zalety kontenerów dependency injection?

Dependency injection to styl kodowania, który ma swoje korzenie w spostrzeżeniu, że delegacja obiektów jest zwykle bardziej użytecznym wzorcem projektowym niż dziedziczenie obiektów (tzn. obiekt ma-relacja jest bardziej użyteczna niż obiekt jest-relacja). Jeszcze jeden składnik jest jednak niezbędny do działania DI, czyli do tworzenia interfejsów obiektowych. Łącząc te dwa potężne wzorce projektowe inżynierowie oprogramowania szybko zdali sobie sprawę, że mogą tworzyć elastyczny, luźno sprzężony kod, a tym samym narodziła się koncepcja iniekcji zależności. Jednak dopiero, gdy object reflection stało się dostępne w niektórych językach wysokiego poziomu, DI naprawdę wystartowało. Komponent reflection jest rdzeniem większości dzisiejszych systemów DI, ponieważ naprawdę fajne aspekty di wymagają możliwości programowego wybierania obiektów i konfigurowania i wprowadzania ich do innych obiektów za pomocą systemu zewnętrznego i niezależnego od samych obiektów.

Język musi zapewniać dobre wsparcie zarówno dla zwykłe techniki programowania obiektowego, a także wsparcie dla interfejsów obiektowych i odbicia obiektów (na przykład Java i C#). Chociaż można budować programy za pomocą wzorców DI w systemach C++, to brak wsparcia dla refleksji w języku właściwym uniemożliwia obsługę serwerów aplikacji i innych platform DI, a tym samym ogranicza wyrazistość wzorców DI.

Mocne strony systemu zbudowanego z wykorzystaniem wzorców DI:

1. kod DI jest znacznie łatwiejsze do ponownego użycia jako funkcjonalność "zależna" jest ekstrapolowana na dobrze zdefiniowane interfejsy, dzięki czemu oddzielne obiekty, których konfiguracja jest obsługiwana przez odpowiednią platformę aplikacji, mogą być dowolnie podłączane do innych obiektów.
2. kod DI jest znacznie łatwiejszy do przetestowania. Funkcjonalność wyrażona przez obiekt może być testowana w czarnej skrzynce, budując "makiety" obiektów implementujących interfejsy oczekiwane przez logikę aplikacji.
3. kod DI jest bardziej elastyczny. Jest to z natury luźno sprzężony kod - do ekstremalne. Pozwala to programiście wybrać sposób łączenia obiektów wyłącznie na podstawie ich wymaganych interfejsów na jednym końcu i wyrażonych interfejsów na drugim.
4. zewnętrzna konfiguracja (Xml) obiektów DI oznacza, że inni mogą dostosować kod w nieprzewidzianych kierunkach.
5. Konfiguracja zewnętrzna jest również oddzieleniem wzorca obaw, ponieważ wszystkie problemy inicjalizacji obiektu i zarządzania współzależnością obiektów mogą być obsługiwane przez aplikację serwer.
6. zauważ, że zewnętrzna konfiguracja nie jest wymagana do użycia wzorca DI, dla prostych połączeń odpowiedni jest często mały obiekt budowniczy. Istnieje kompromis w elastyczności między nimi. Obiekt builder nie jest tak elastyczną opcją jak zewnętrznie widoczny plik konfiguracyjny. Twórca systemu DI musi ważyć zalety elastyczności nad wygodą, dbając o małą skalę, drobnoziarnistą kontrolę nad konstrukcją obiektu, wyrażoną w plik konfiguracyjny może zwiększyć zamieszanie i koszty konserwacji w dół linii.

Zdecydowanie kod DI wydaje się bardziej uciążliwy, wady posiadania wszystkich plików XML, które konfigurują obiekty do iniekcji do innych obiektów wydaje się trudne. Jest to jednak punkt systemów DI. Możliwość mieszania i dopasowywania obiektów kodu jako serii ustawień konfiguracyjnych pozwala na budowanie złożonych systemów przy użyciu kodu innych firm przy minimalnym kodowaniu z twojej strony.

The przykład podany w pytaniu dotyka jedynie powierzchni siły ekspresyjnej, jaką może zapewnić odpowiednio ujęta biblioteka obiektów DI. Z pewną praktyką i dużą samodyscypliną większość praktyków DI odkrywa, że mogą budować systemy, które mają 100% pokrycie testowe kodu aplikacji. Ten jeden punkt jest niezwykły. Nie jest to 100% pokrycie testowe małej aplikacji kilkuset linii kodu, ale 100% pokrycie testowe aplikacji składających się z setek tysięcy linie kodu. Nie jestem w stanie opisać żadnego innego wzorca projektowego, który zapewnia ten poziom testowalności.

Masz rację, ponieważ aplikacja składająca się z zaledwie 10 linii kodu jest łatwiejsza do zrozumienia niż kilka obiektów plus seria plików konfiguracyjnych XML. Jednak, podobnie jak w przypadku najpotężniejszych wzorców projektowych, zyski znajdują się w miarę dodawania nowych funkcji do systemu.

Krótko mówiąc, aplikacje na dużą skalę oparte na DI są zarówno łatwiejsze do debugowania, jak i łatwiej zrozumieć. Chociaż konfiguracja Xml nie jest 'sprawdzana w czasie kompilacji', wszystkie usługi aplikacji, o których jest świadomy ten autor, dostarczą deweloperowi komunikaty o błędach, jeśli spróbuje wstrzyknąć obiekt o niekompatybilnym interfejsie do innego obiektu. Większość z nich zapewnia funkcję "sprawdzania", która obejmuje wszystkie znane konfiguracje obiektów. Można to łatwo i szybko zrobić, sprawdzając, czy wstrzykiwany obiekt A implementuje interfejs wymagany przez obiekt B dla wszystkich skonfigurowanych zastrzyki obiektowe.

To trochę załadowane pytanie, ale zazwyczaj zgadzam się, że ogromna ilość konfiguracji xml nie przynosi zbyt wielu korzyści. Lubię, aby moje aplikacje były tak lekkie, jak to możliwe, w tym potężne frameworki.

Upraszczają kod wiele razy, ale mają również narzut złożoności, która sprawia, że śledzenie problemów jest raczej trudne (widziałem takie problemy z pierwszej ręki, a proste Java byłoby o wiele wygodniej radzić sobie z).

Myślę, że to zależy trochę od stylu, i to, co jest wygodne... czy lubisz latać własnym rozwiązaniem i mieć tę zaletę, że znasz je na wylot, czy też opierasz się na istniejących rozwiązaniach, które mogą okazać się trudne, gdy konfiguracja nie jest odpowiednia? To wszystko jest kompromitacją.

Jednak konfiguracja XML jest dla mnie trochę kłopotliwa... Staram się tego unikać za wszelką cenę.

Za każdym razem, gdy zmienisz kod na dane, robisz krok we właściwym kierunku.

Kodowanie czegokolwiek jako danych oznacza, że sam kod jest bardziej ogólny i wielokrotnego użytku. Oznacza to również, że Twoje dane mogą być określone w języku, który dokładnie do nich pasuje.

Ponadto plik XML można wczytać do GUI lub innego narzędzia i łatwo manipulować nim. Jak byś to zrobił na przykładzie kodu?

Ciągle faktoruję rzeczy, które większość ludzi wdrożyłaby jako kod do danych, to sprawia, że kod pozostaje dużo czystsze. Uważam, że to nie do pomyślenia, że ludzie będą tworzyć menu w kodzie, a nie jako dane-powinno być oczywiste, że robienie tego w kodzie jest po prostu złe z powodu kotła.

Powodem użycia kontenera DI jest to, że nie musisz mieć miliarda wstępnie skonfigurowanych właściwości w kodzie, które są po prostu getterami i seterami. Czy naprawdę chcesz zakodować wszystkie z nowym x()? Oczywiście, możesz mieć domyślne, ale kontener DI pozwala na tworzenie singletonów, co jest niezwykle łatwe i pozwala skupić się na szczegółach kodu, a nie na różnych zadaniach inicjalizacji go.

Na przykład, Spring pozwala zaimplementować InitializingBean interface i Dodaj metodę afterPropertiesSet (możesz również określić "INIT-method", aby uniknąć łączenia kodu ze Springiem). Metody te pozwolą Ci upewnić się, że każdy interfejs określony jako pole w Twojej instancji klasy jest poprawnie skonfigurowany podczas uruchamiania, a następnie nie musisz już sprawdzać żadnych getterów i setterów (zakładając, że pozwolisz Twoim singletonom pozostać bezpiecznym dla wątków).

Ponadto znacznie łatwiej jest wykonać złożone inicjalizacje za pomocą DI kontener zamiast robić je samemu. Na przykład pomagam przy użyciu XFire (nie CeltiXFire, używamy tylko Javy 1.4). Aplikacja korzystała z Springa, ale niestety korzystała z usług XFire.mechanizm konfiguracji xml. Kiedy zbiór elementów musiał zadeklarować, że ma ZERO lub więcej instancji zamiast jednej lub więcej instancji, musiałem nadpisać część dostarczonego kodu XFire dla tej konkretnej usługi.

Istnieją pewne domyślne wartości Xfire zdefiniowane w schemacie Spring beans. Więc, gdybyśmy używali Springa do konfigurowania usług, można by było użyć fasoli. Zamiast tego, stało się to, że musiałem dostarczyć instancję określonej klasy w usługach.plik xml zamiast używać fasoli. Aby to zrobić, musiałem podać konstruktor i ustawić referencje zadeklarowane w konfiguracji XFire. Prawdziwa zmiana, której potrzebowałem, wymagała przeciążenia jednej klasy.

<bean id="base" parent="RootXFireBean">
    <property name="secondProperty" ref="secondBean" />
</bean>

<bean id="secondBean" parent="secondaryXFireBean">
    <property name="firstProperty" ref="thirdBean" />
</bean>

<bean id="thirdBean" parent="thirdXFireBean">
    <property name="secondProperty" ref="myNewBean" />
</bean>

<bean id="myNewBean" class="WowItsActuallyTheCodeThatChanged" />

Zamiast tego wyglądało to bardziej TAK:

public class TheFirstPointlessClass extends SomeXFireClass {
    public TheFirstPointlessClass() {
        setFirstProperty(new TheSecondPointlessClass());
        setSecondProperty(new TheThingThatWasHereBefore());
    }
}

public class TheSecondPointlessClass extends YetAnotherXFireClass {
    public TheSecondPointlessClass() {
        setFirstProperty(TheThirdPointlessClass());
    }
}

public class TheThirdPointlessClass extends GeeAnotherXFireClass {
    public TheThirdPointlessClass() {
        setFirstProperty(new AnotherThingThatWasHereBefore());
        setSecondProperty(new WowItsActuallyTheCodeThatChanged());
    }
}

public class WowItsActuallyTheCodeThatChanged extends TheXFireClassIActuallyCareAbout {
    public WowItsActuallyTheCodeThatChanged() {
    }

    public overrideTheMethod(Object[] arguments) {
        //Do overridden stuff
    }
}

Więc wynik netto jest taki, że cztery dodatkowe, w większości bezsensowne klasy Javy musiały zostać dodane do bazy kodowej, aby osiągnąć efekt, który osiągnęła jedna dodatkowa klasa i kilka prostych informacji o kontenerze zależności. To nie jest " wyjątek to dowodzi zasady", to jest zasada...obsługa dziwactw w kodzie jest znacznie czystsza, gdy właściwości są już dostępne w kontenerze DI i po prostu zmieniasz je, aby pasowały do specjalnej sytuacji, co zdarza się częściej niż nie.

I have your answer

Istnieją oczywiście kompromisów w każdym podejściu, ale zewnętrzne pliki konfiguracyjne XML są przydatne dla rozwoju przedsiębiorstw, w których systemy budowania są używane do kompilacji kodu, a nie IDE. Korzystając z systemu kompilacji, możesz chcieć wprowadzić pewne wartości do kodu - na przykład wersję kompilacji (co może być bolesne, gdy trzeba będzie aktualizować ręcznie za każdym razem, gdy kompilujesz). Ból jest większy, gdy Twój system budowania ściąga kod z niektórych system kontroli wersji. Modyfikowanie prostych wartości w czasie kompilacji wymagałoby zmiany pliku, zatwierdzenia go, kompilacji, a następnie odwrócenia za każdym razem dla każdej zmiany. Nie są to zmiany, które chcesz wprowadzić do kontroli wersji.

Inne przydatne przypadki użycia dotyczące systemu budowania i zewnętrznych configów:

• wstrzykiwanie stylów/arkuszy stylów dla pojedynczej bazy kodu dla różnych kompilacji
• wstrzykiwanie różnych zestawów dynamicznych treści (lub odniesień do nich) dla Twojego single code base
• wstrzykiwanie kontekstu lokalizacji dla różnych buildów / klientów
Nie jest to jednak możliwe, ponieważ nie jest to możliwe.]}

Update: Wszystkie powyższe przykłady dotyczyły rzeczy, które niekoniecznie wymagały zależności od klas. Ale można łatwo budować przypadki, w których potrzebny jest zarówno złożony obiekt, jak i automatyzacja - na przykład:

• wyobraź sobie, że masz system, w którym monitorował ruch na twojej stronie. W zależności od liczby współbieżnych użytkowników włącza / wyłącza mechanizm logowania. Być może, gdy mechanizm jest wyłączony, obiekt wstępny jest umieszczany na swoim miejscu.
• wyobraź sobie, że masz system konferencji internetowych, w którym w zależności od # użytkowników, chcesz wyłączyć możliwość robienia P2P w zależności od # uczestników

Nie musisz rekompilować kodu za każdym razem, gdy zmienisz coś w konfiguracji. Uprości to wdrażanie i konserwację programu. Na przykład możesz zamienić jeden komponent na inny za pomocą tylko 1 zmiany w pliku konfiguracyjnym.

Możesz wstawić nową implementację dla girlfriend. Więc nowa kobieta może być wstrzyknięta bez rekompilacji kodu.

<bean id="jane" class="foo.bar.HotFemale">
  <property name="age" value="19"/>
</bean>
<bean id="mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="john" class="foo.bar.Male">
  <property name="girlfriend" ref="jane"/>
</bean>

(powyższe zakłada, że Female i HotFemale implementują ten sam interfejs GirlfFriend)

W świecie. NET większość frameworków IoC dostarcza zarówno XML, jak i konfigurację kodu.

StructureMap i Ninject, na przykład, używają interfejsów fluent do konfigurowania kontenerów. Nie musisz już używać plików konfiguracyjnych XML. Spring, który istnieje również w. Net, w dużej mierze opiera się na plikach XML, ponieważ jest to jego historyczny główny interfejs konfiguracyjny, ale nadal można programowo konfigurować kontenery.

Łatwość łączenia częściowych konfiguracji W ostateczną kompletną konfigurację.

Na przykład w aplikacjach internetowych model, widok i kontrolery są zazwyczaj określone w oddzielnych plikach konfiguracyjnych. Za pomocą podejścia deklaratywnego można załadować np.: {[0]}

Lub załaduj za pomocą innego interfejsu użytkownika i kilku dodatkowych kontrolerów: {[1]}

Aby zrobić to samo w kodzie, wymagana jest infrastruktura do łączenia częściowych konfiguracji. Nie niemożliwe do zrobienia w kodzie, ale z pewnością łatwiejsze do zrobienia przy użyciu frameworka IoC.

Często ważnym punktem jest Kto zmienia konfigurację po napisaniu programu. Z konfiguracją w kodzie domyślasz się, że osoba go zmieniająca ma takie same umiejętności i dostęp do kodu źródłowego itp. jak oryginalny autor.

W systemach produkcyjnych bardzo praktyczne jest wyodrębnienie niektórych podzbiorów ustawień (np. wiek w twoim przykładzie) do pliku XML i umożliwienie np. administratorowi systemu lub support personal zmiany wartości bez podawania im pełnej moc nad kodem źródłowym lub innymi ustawieniami-lub po prostu odizolować je od złożoności.

Z wiosennej perspektywy mogę dać ci dwie odpowiedzi.

Najpierw konfiguracja XML nie jest jedynym sposobem na zdefiniowanie konfiguracji. Większość rzeczy można skonfigurować za pomocą adnotacji, a rzeczy, które należy zrobić za pomocą XML, to konfiguracja kodu, którego nie piszesz, jak Pula połączeń, której używasz z biblioteki. Spring 3 zawiera metodę definiowania konfiguracji DI za pomocą Javy, podobną do ręcznie zwijanej konfiguracji DI w twoim przykładzie. Więc użycie Springa nie oznacza, że musisz użyć pliku konfiguracyjnego opartego na XML.

Po drugie wiosna to znacznie więcej niż tylko rama DI. Posiada wiele innych funkcji, w tym zarządzanie transakcjami i AOP. Konfiguracja Spring XML łączy wszystkie te pojęcia. Często w tym samym pliku konfiguracyjnym określam zależności bean, ustawienia transakcji i dodaję fasole sesyjne, które faktycznie obsługiwały za pomocą AOP w tle. Znajduję konfigurację XML zapewnia lepsze miejsce do zarządzania wszystkimi tymi funkcjami. Uważam również, że konfiguracja oparta na adnotacjach i konfiguracja XML skalują się lepiej niż konfiguracja oparta na Javie.

Ale rozumiem twój punkt widzenia i nie ma nic złego w definiowaniu konfiguracji iniekcji zależności w Javie. Zwykle robię to sam w testach jednostkowych i kiedy pracuję nad projektem na tyle małym, że nie dodałem frameworka DI. Normalnie nie podaję konfiguracji w Javie, bo dla mnie to jest ten rodzaj kodu, który staram się odpisać, gdy zdecydowałem się użyć Springa. Jest to jednak preferencja, nie oznacza to, że konfiguracja XML jest lepsza od konfiguracji opartej na Javie.

Sprężyna ma również ładowarkę właściwości. Za pomocą tej metody ustawiamy zmienne zależne od środowiska (np. rozwój, testowanie, akceptacja, produkcja, ...). Może to być na przykład kolejka do słuchania.

Jeśli nie ma powodu, dla którego właściwość miałaby się zmieniać, nie ma również powodu, aby skonfigurować ją w ten sposób.

Twoja sprawa jest bardzo prosta i dlatego nie wymaga kontenera IoC (Inwersja sterowania), takiego jak Spring. Z drugiej strony, gdy " programujesz do interfejsów, a nie implementacji "(co jest dobrą praktyką w OOP), możesz mieć kod w ten sposób:

IService myService;
// ...
public void doSomething() {
  myService.fetchData();
}

(zauważ, że typ myService to IService -- interfejs, a nie konkretna implementacja). Teraz może być przydatne, aby kontener IoC automatycznie dostarczył poprawną konkretną instancję IService podczas inicjalizacji - gdy masz wiele interfejsów i wielu implementacji, może być kłopotliwe, aby zrobić to ręcznie. Główne zalety kontenera IoC (dependency injection framework) to:

• zewnętrzna konfiguracja mapowania pomiędzy interfejsami i ich konkretnymi implementacjami
• kontener IoC radzi sobie z trudnymi problemami, takimi jak rozwiązywanie skomplikowanych wykresów zależności, zarządzanie żywotnością komponentu itp.
• oszczędzasz czas kodowania, ponieważ dostarczasz mapowania deklaratywnie, a nie w Kodeks postępowania
• odwrócenie Zasady sterowania pozwala na łatwe Testowanie jednostek, ponieważ można zastąpić rzeczywiste implementacje fałszywymi (np.]}

Inicjalizacja w pliku konfiguracyjnym XML uprości pracę z debugowaniem / adaptacją z klientem, który wdrożył Twoją aplikację na swoich komputerach. (Ponieważ nie wymaga rekompilacji + wymiany plików binarnych)

Jednym z najbardziej atrakcyjnych powodów jest " Zasada Hollywood ": nie dzwoń do nas, my zadzwonimy do ciebie. Komponent nie jest wymagany do samodzielnego wyszukiwania innych komponentów i usług; zamiast tego są one dostarczane do niego automatycznie. W języku Java oznacza to, że nie jest już konieczne szukanie JNDI wewnątrz komponentu.

Jest również o wiele łatwiej przetestować komponent w izolacji: zamiast dać mu rzeczywistą implementację komponentów, których potrzebuje, po prostu używać (ewentualnie automatycznie generowanych) moków.