Alternatywa dla kontenera DI

Odpowiedz Nowy wątek
2018-11-27 10:56
0

Cześć
Ostatnio czytam sobie rzeczy i spotkałem się z opinią, że kontener DI to ZUO. Załóżmy że chcę porzucić kontener, ale nie rezygnować z DI. Tylko jeśli nie kontener to co? Szukałem alternatywy jak używać z DI bez kontenera i niestety bez rezultatów. Gdzieś te instancje muszą zostać stworzone. Gdzie? Nie wyobrażam sobie klejenia wszystkiego ręcznie w Run'ie czy jak tam nazwiemy entry point. Z resztą (moim skromnym zdaniem) dalej jest to kontenerowe podejście - tylko zamiast używać framework'a to wykuwamy koło od nowa

Tak więc, czy macie jakąś sensowną alternatywę dla kontenera DI?

Pozostało 580 znaków

2018-11-27 11:37
0

Nie wyobrażam sobie klejenia wszystkiego ręcznie w Run'ie czy jak tam nazwiemy entry point

Tak właśnie to wygląda bez kontenera ;-)
Przy czym jeśli wykorzystasz wzorzec fabryka, staje się to całkiem przyjemne w kodowaniu.


Pozostało 580 znaków

2018-11-27 11:42
0

Nie wyobrażam sobie klejenia wszystkiego ręcznie w Run'ie czy jak tam nazwiemy entry point.

Nie musisz tworzyć wszystkiego w jednej metodzie. Możesz ją podzielić na klasy i metody. Jeśli jawna konstrukcja grafu zależności będzie mocno skomplikowana to najprawdopodobniej będzie to oznaczało iż aplikacja jest słabo zmodularyzowana (tzn jest zbyt dużo powiązań między odległymi klasami). Jakub Nabrdalik pokazuje na swoich prezentacjach modularyzację opartą o package scope w Javie. W takiej sytuacji wydaje mi się, że wstrzykiwanie zależności mogłoby odbywać się dwupoziomowo - każdy pakiet ma własną logikę do konstruowania hierarchii zależności z tego pakietu, a ponad tym jest jeszcze logika spinająca moduły (pakiety) do kupy.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2018-11-27 11:44

Pozostało 580 znaków

2018-11-27 11:55
0

Możesz podzielić projekt na moduły, gdzie każdy moduł tworzy się sam (na zasadzie, że tworzysz po prostu obiekt modułu, czy to jakimś obiektem z konfiguracji, czy czymś). Tak, nadal potrzebujesz jednego miejsca, żeby to spiąć do kupy przez co musisz zrobić to sam (rozwiązując od razu problemy z zależnościami. Przy okazji na pewno unikniesz cykli w zależnościach modułów). W zamian za to dostajesz pełną kontrole nad tym co, kiedy, gdzie i jak startuje.


Szukam pracy na pół etatu, Java, Poznań

Pozostało 580 znaków

2018-11-27 13:42
0

@Tyvrel: To popatrz sobie jak działa Guice. I zasadniczo ręczne wstrzykiwanie zależności jest (w dużym uproszczeniu) prawdopodobnie bardzo podobe...


Nie pomagam przez PM. Pytania zadaje się na forum.

Pozostało 580 znaków

2018-12-05 17:51
0

Jakoś się dało pisać te programy bez użycia kontenerów DI. Co do tego zła, to też można wybrać większe i mniejsze. Może popadam w paskudny relatywizm moralny, ale jednak czym innym jest taki Spring i jego "znajdź wszystkie beany implementujące jakiś tam interface i wstrzyknij jako listę bezpośrednio do pola prywatnego obiektu", a czym innym taki Dagger 2 z jego "napisz mi metody fabrykujące do wskazanych klas".

Jakoś się dało pisać te programy bez użycia kontenerów DI dało sie też pisać w asemblerze, a potem bez bibliotek, a potem bez gotowych komponentów jak bazy danych czy kolejki... ;) Nadal się da! - Shalom 2018-12-06 09:27

Pozostało 580 znaków

2018-12-11 20:38
1

Odniose się do tego komentarza, bo mnie ciśnienie podnosi :-)

` Jakoś się dało pisać te programy bez użycia kontenerów1 DI dało sie też pisać w asemblerze, a potem bez bibliotek, a potem bez gotowych komponentów jak bazy danych czy kolejki... ;) Nadal się da! - Shalom 2018-12-06 09:27

To jest przykład tak zwanej fałszywej alternatywy. Można używać bibliotek. Można uzywać bardziej zwięzłych języków programowania, a nadal nie widzieć korzyści w kontenerowym DI.
Ja nie widze. To znaczy widzę trochę strat, które nie są rekompensowane przez potencjalne korzyści. Mam mniej więcej o kontenerowym DI takie zdanie jak o GOTO.
Jak weźmiesz bardzo mały lub specyficzny fragment kodu to pokażesz, że dzieki GOTO (Adnotacjom, DI) można coś zrobić szybciej. W średniej wielkości kodzie (więcej niż jeden CRUD :-) ) już różnica ilości kodu wychodzi praktycznie żadna, widzę za to bajzel jaki ta magia powoduje.

Mam nawet taką metrykę spustoszenia springowego/DI - klasa z największą ilością @Autowired/ Injectionów. 15tki-18tki to normalka.

Żeby nie było, kiedyś (na pewno jeszcze w 2013) kontenery, adnotacje mnie bardzo jarały i byłem praktykującym wyznawcą.

Najlepszy zresztą przykład, ze kontenery DI nie są potrzebne daje ... Spring. Nie znam kodu wszystkich modułów, ale te co trochę znam nie używają Springa(!), ani żadnego kontenerowego DI , mimo że mogłyby, bo od spring-core/spring-beans zależą :-). Przykład Spring-data-jpa, spring-tx. Może kod nie jest idealny, ale całkiem ładnie pokazuje jak fabryki rozwiazują problem.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 6x, ostatnio: jarekr000000, 2018-12-11 21:15

Pozostało 580 znaków

2018-12-11 21:02
2
jarekr000000 napisał(a):

Mam nawet taką metrykę spustoszenia springowego/DI - klasa z największą ilością @Autowired/ Injectionów. 15tki-18tki to normalka.

To mnie zawsze zastanawia. Czy jeżeli by zabrać możliwość ałtołajerowania, to czy ludzie by otrzeźwieli i pisaliby klasy bez przesadzania z zależnościami? Mam wrażenie, że konstruktor to taki bicz na lenistwo i gdyby wymusić korzystanie z niego dla zależności, to już łatwiej byłoby zorganizować odpowiednią strukturę klas. Z drugiej strony kontenery wcale nie przeszkadzają w rozsądnym pisaniu kodu (bardziej ułatwiają bylejakość) i kocham Daggera 2.

edytowany 2x, ostatnio: Michał Sikora, 2018-12-11 21:05
Z tym biczem to dokładnie. Zdarza mi się zrobić klasę z 5 cioma zależnościami, ale już wtedy to bardzo boli i trzeba kombinować. Niestety jak się przekroczy 10, co przy kontenerach jest zupełnie normalne. To na kombinowanie zwykle już jest za późno. Będzie bardzo, bardzo bolało. - jarekr000000 2018-12-11 21:18
konstruktor to taki bicz na lenistwo i gdyby wymusić korzystanie z niego dla zależności — potem będzie generowanie konstruktorów przez lomboka. - Afish 2018-12-17 18:54
To akurat nie jest problem, bo te konstruktory muszą być tak czy inaczej wywołane przez nas. - Michał Sikora wczoraj, 07:33
Jak zakładasz, że ktoś będzie je ręcznie wołał, to tak, ale równie dobrze może wrzucić adnotację i kontener je wywoła. W dotnecie na przykład wstrzykiwanie przez konstruktor jest normą, nie ma lomboka, więc trzeba je pisać ręcznie, ale i tak nikt ich z palca nie wywołuje. - Afish wczoraj, 15:15
Nie mam sympatii do Lomboka, ale to akurat problem kontenerów a nie Lomboka, że pozwalają dostarczyć wszystko wszędzie i dajemy konstruktory z 10 argumentami. Bo przecież i tak siem wszczyknie. - Michał Sikora wczoraj, 16:05

Pozostało 580 znaków

2018-12-11 21:12
1

Wymuszenie ceremonii przepisywania argumentów z konstruktora do pól prywatnych pewnie mogłoby minimalnie poprawić sytuację, ale dalej magiczne wstrzykiwanie oznaczałoby, że nikt nie wiedziałby jak naprawdę wygląda graf zależności. Chociaż z drugiej strony jakieś narzędzia do wizualizacji grafu są, np: https://github.com/google/guice/wiki/Grapher Przy wielu klasach z kilkunastoma wstrzykniętymi parametrami taki graf zależności pewnie byłby nie do ogarnięcia przez zwykłego śmiertelnika.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2018-12-11 21:29
1
jarekr000000 napisał(a):

To jest przykład tak zwanej fałszywej alternatywy. Można używać bibliotek. Można uzywać bardziej zwięzłych języków programowania, a nadal nie widzieć korzyści w kontenerowym DI.
Ja nie widze. To znaczy widzę trochę strat, które nie są rekompensowane przez potensjalne korzyści. Mam mniej więcej o kontenerowym DI takie zdanie jak o GOTO.
Jak weźmiesz bardzo mały lub specyficzny fragment kodu to pokażesz, że dzieki GOTO (Adnotacjom, DI) można coś zrobić szybciej. W średniej wielkości kodzie (więcej niż jeden CRUD :-) ) już różnica ilości kodu wychodzi praktycznie żadna, widzę za to bajzel jaki magia powoduje.

Mam nawet taką metrykę spustoszenia springowego/DI - klasa z największą ilością @Autowired/ Injectionów. 15tki-18tki to normalka.

Nikt nie każe wstawiać zależności przez @Autowired na polach. Jest kolosalna różnica pomiędzy dynamic proxy ze Springa i wstrzykiwaniem zależności refleksjami do klasy, a automatycznym tworzeniem fabryk przez takiego Daggera 2. Warto pamiętać, że te biblioteki / frameworki nikogo nie zmuszają to pisania kiepskiego kodu. Jak ktoś walnął klasę z 20 zależnościami to problemem jest głupota programisty a nie DI. Chociaż oczywiście Spring potrafi czasami zamaskować partactwo.

Pozostało 580 znaków

2018-12-11 22:44
1

Z tym dagerrem to mam problem, bo wszyscy pisza jaki jest lepszy od innych magii. Compile time etc. A ja widze tylko kolejną kaszankę :
Przykład http://www.vogella.com/tutorials/Dagger/article.html

component.inject(this); serio ?

Ale strzelam, że pewnie gdzieś, ktoś ma lepszy przykład.

20 zależnościami to problemem jest głupota programisty a nie DI.

Zawsze jest głupota programisty, ale ja to widze tak, że właśnie jak robimy głupotę to zaczyna być widać zyski z kontenera DI. (to z prezentacji Tomera Gabela).

Jest jeden przypadek, gdzie widzę sens kontenerów DI (opartych o skanowanie klas) - runtimowe rozpoznawanie zależności, o których nic nie wiadomo w czasie kompilacji - czyli pluginy.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 5x, ostatnio: jarekr000000, 2018-12-11 22:49
Pokaż pozostałe 4 komentarze
Przewaga pojawi się podczas testowania moim zdaniem. Podmieniam np. moduł płatności na jakiś sztuczny wstawiając go do grafu i cała reszta jest skonfigurowana tak samo. Natomiast biorąc pod uwagę specyfikę Androida, to by było bardzo kiepsko bez Daggera. - Michał Sikora 2018-12-11 23:15
To tak jak u mnie, tylko bez daggera :-) Ale nie wiem jak to jest na dłuższą metę w Androidzie. W czasach servletów, jsp i aplication serwera, ciężko było bez kontenera DI i faktycznie wtedy Spring miał sens. - jarekr000000 2018-12-11 23:24
A jak to uzyskujesz? Masz jakiś domyślnie skonfigurowany graf i na nim metodę np. withPaymentModule(module), która buduje od nowa tylko z podmienionym modułem? - Michał Sikora 2018-12-11 23:26
Typowy przykład: https://github.com/javaFunAga[...]/pongi/users/UsersModule.java to zresztą filozoficznie podobne do daggera IMO (może nawet sie trochę kiedyś inspirowałem). Składanie do kupy: https://github.com/javaFunAga[...]a/pl/setblack/pongi/Main.java . Takie withCośTamCośTam to mam w kotlinowych projektach (zresztą .copy( idealnie się do tego nadaje). - jarekr000000 2018-12-11 23:32
No, to w zasadzie na to samo wychodzi. Odrobinę więcej kodu musisz napisać, ale za to jest to bardziej przejrzyste. W Googlu w sumie Daggera 2 potrzebowali, bo mieli te mityczne aplikacje na tysiące modułów. Dagger robi bardzo dużo optymalizacji w wygenerowanym kodzie i ponoć przyspieszył im wykonywanie zapytań o jakieś 13% w skali Googla i to w wersji beta (chociaż zakładam, że to było w odniesieniu do Guice czy czegoś takiego). Dzisiaj pewnie jeszcze lepsze wyniki osiągneli dzięki niemu. Ale to raczej jako ciekawostkę podaję a nie jako coś, co mi spędza sen z powiek. - Michał Sikora 2018-12-11 23:38

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0