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.
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
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.