Czemu używacie kontenerów IoC?

No właśnie, po co? Przecież można obiekty tworzyć przez new, a kontenery są magiczne i można z nich wyciągać króliki jak z kapelusza. https://blog.ploeh.dk/2014/06/10/pure-di/

Otwieram dyskusję izomorficzną do wątku o mockach.

IoC jest

• banalne - gdy nie ma jakiegoś wyboru, co wstrzykiwać. Łatwe do zastapienia "wstrzykiwaniem" w new Konstruktor
• gdy zawartość wstrzykiwana jest dynamicznie określana w zależności od miejsca wstrzykiwania / nazwy (z adnotacji / atrybutu ) / dymanicznej konfiguracji runtime / whatever.
  Emocjonalnie lubię te "managery": moduły Guice czy producery CDI.
  Zaznaczam, "lubię" emocjonalnie, a nie wypowiadam się czy długofalowo / inżynieryjnie / naukowo to słuszne, czy nie.
  Wydaje mi się, że elementy decyzyjne są skupione w dobrym miejscu - trudne do zastąpienia "wstrzykiwaniem" w new Kontruktor, bo byłby to powrót do pewnego brzydkiego stylu spagetti sprzed lat.
  Jest nienegowaną zaletą kontenerów DI, że upraszcza importy / listy parametrów w tych pionach, gdzie by (dziś) było new Konstruktor, sorry, ale to (=mnożenie importów / parametrów konstruktora) nie zawsze by było zdrowe
  Moduł Guice (odpowiednik CDI) jest takim "trochę brudniejszym" miejscem, w sensie jest tam wiele importów - ale kodu sekwencyjnego to tam prawie nie ma, więc ta "brudność" jest specyficzna

Nigdy w naszym kodzie nie siedemnastu pól @Inject, jeden, góra dwa (np w Apache Wicket konstruktory już są zajęte).

Przyszły czasy, że modne jest się wstydzić wstrzykiwania. Nie ma czego - ale tak, jeśli była przesada, np siedemnaście wstrzykiwanych pól.
raczej można mówić o "rytmie słonecznym jedenastoletnim" w rotacyjnych zmianach mody "jak nie wstrzykujesz to jesteś ... " / "jak wstrzykujesz to jesteś ... "

Wydaje mi się, że elementy decyzyjne są skupione w dobrym miejscu - trudne do zastąpienia "wstrzykiwaniem" w new Kontruktor, bo byłby to powrót do pewnego brzydkiego stylu spagetti sprzed lat.

Jak wygląda ten brzydki styl spaget sprzed lat?

Jedno nie wyklucza drugiego? Moje zarządzane obiekty wyglądają np. tak: https://github.com/Pharisaeus/almost-s3/blob/master/domain/src/main/java/net/forprogrammers/almosts3/domain/FileAccessService.java i w zasadzie nic nie wskazuje że składa je jakieś IoC. A samo składanie wygląda tak: https://github.com/Pharisaeus/almost-s3/blob/master/server/src/main/java/net/forprogrammers/almosts3/server/configuration/ApplicationConfiguration.java i równie dobrze mogłoby tam nie być tego kontenera wcale...
Niemniej jak te same obiekty przekazujesz do kilku innych to okazuje sie, ze wygodnie zrobić sobie jakąś sprytną abstrakcje nad tym przekazywaniem (coś w stylu singletona czy service locatora), żeby nie zginąć próbując ustalić kolejność tworzenia obiektów w duzej aplikacji i nagle wychodzi nam własne bieda-IoC :D

@Shalom:

Shalom napisał(a):

...

Niemniej jak te same obiekty przekazujesz do kilku innych to okazuje sie, ze wygodnie zrobić sobie jakąś sprytną abstrakcje nad tym przekazywaniem (coś w stylu singletona czy service locatora), żeby nie zginąć próbując ustalić kolejność tworzenia obiektów w duzej aplikacji i nagle wychodzi nam własne **bieda-IoC **:D

Dobrze Waść prawisz ...
Moja droga do IoC prowadziła od bieda-service-locatorów. Service chce mieć uchwyt - i mieć pewność, że są wystartowane - serviców bardziej bazowych od niej itd ...

To były czasy Spinga XMLowego, odrzucało do tego na kilometr, musiał być poza zasięgiem rzygania.
Guice IoC (wbrew nazwie) był jak powiew prawdziwej Wiosny. Ta przyjemność wyje.... nia do kosza kilkudziesięciu klas service-lokatorów, tego się nie da opisać
Na marginesie, Locator jest bliski singletona, i tu jebudu ... "zróbcie panowie tak, żeby w programie dało się wybrać inną firmę" (znaczna apka finansowa pod Swingiem) ....

Ty, ja, wszyscy, łącznie z apostołami injekcji new Kontruktor nie byliśmy idiotami 10-15 lat temu czy innymi upośledzonymi. IoC to naprawdę był dobry krok.
Że współcześnie wynaturzenia wstrzykiwania spowodowały w czambuł negatywną ocenę "Inject to rak" .... bosch ... to za kilka lat będziemy określać injekcję *)
w new Kontruktor jako rak.

Pa. lecę sobie coś wstrzyknąć

*) religijną injekcię

Nie używam. Są jakiś dla Scali?

Przecież można obiekty tworzyć przez new

No to tworzę ;] (Guice IoC)

bind(EventBus.class).toInstance(new EventBus());

W Javie/Kotlinie bo są wygodne, bo ładnie porządkują dostarczanie zależności w systemie. Aczkolwiek nie wszędzie się da dobrze...

Przy jednym projekcie pisanym w C++ musieliśmy się posiłkować ręcznie pisanymi Locatorami, bo z boost:DI były jakieś niestworzone problemy przez to, że projekt operował bardzo dużo na staticach.

Kiedyś używałem, bo czułem, że to PRO i zawsze była takie fajne uczucie jak beany się poskładały i system wystartował bez obsrania się. (ale wypas).
Dodatkowo nie znałem alternatyw do aspektów runtimowych.

Od iluś już lat jednak nie używam (chyba, że stary system albo architekt mnie zmusza) i jakoś nie umiem sobie wyobrazić powrotu do beanów.

Ja bardziej używam, niż nie używam, ale czasami ciężko mi się zdecydować czy wolę rozwiązywać problemy klasy skąd tu się bierze ten obiekt czy jednak ktoś stworzył nowy, własny wzorzec konstrukcyjny. Sporo zależy od narzędzia. Adnotacje łupane w runtime (np. Spring) są bardziej upierdliwe niż takie tworzące kod na etapie kompilacji (Dagger, Guice). Pisząc obiektowo, mam do wyboru albo użyć jakiegoś narzędzia do składania obiektów w większe obiekty, albo mieć w kodzie sporo klas odpowiedzialnych za konstruowanie czegoś. Moje generalne podejście jest takie, że im mniej kodu piszę, tym mniej błędów popełnię. Drugi powód dla którego lubię obibliotekowane IoC to wprowadzenie standardowego w ramach aplikacji sposobu tworzenia obiektów, zamiast Adam woli factory, Bogdan buildery a Czesiu przeczytał jakąś starą książkę o IoC i wszędzie pakuje proxy.