Wpis z mikrobloga

Hej #androiddev korzystacie z Dependency Injection i Daggera? Nie implementowałem nigdy sam, generalnie znam koncept DI ale ni jak nie rozumiem do czego można go wykorzystać w Androidzie przy typowych apkach typu pobierz coś z serwera i wyświetl w liście. Wg mnie koszt czasowy z napisania całej daggerowej otoczki nie jest wart korzyści jakie daje. Plus dodatkowo wg mnie strasznie utrudnia czytanie kodu - a osobom które nie mają styczności z Daggerem niemal uniemożliwia. Co o tym myślicie?
  • 8
@fegwegw: Przykro mi ale Twoja wypowiedź totalnie nic nie wnosi do dyskusji, odebrałem to jako "skoro zadajesz takie pytania to tego nie rozumiesz, doucz się". Od rana wertuję blogi i wpisy i w każdym pojawia się to samo - dziesiątki annotacji, dodatkowe moduły, klasy tylko po to żeby uniknąć wpisania w jednym miejscu new ItemsRepository() albo ServiceFactory.createService(). Liczyłem na jakiś życiowy przykład: do czego to wykorzystujecie i jakie to ma
@Mithrindil: Zapytałeś: "co o tym myślicie?", to Ci napisałem, co o tym myślę.

Przykłady? Nie prosiłeś w pierwszym poście, ale proszę:

- zmiana implementacji usługi sprowadza się do zmiany bindowania, zamiast orania po X klasach, w których używasz 'new'.

- ułatwia testowanie, bo dostarczasz zależności z zewnątrz, zatem możesz w teście dostarczy tam co chcesz, np. mocka.
@Mithrindil:

Wg mnie koszt czasowy z napisania całej daggerowej otoczki nie jest wart korzyści jakie daje.


I jeszcze powiedz, że piszesz całą logikę w aktywnościach ( ͡° ͜ʖ ͡°)

Plus dodatkowo wg mnie strasznie utrudnia czytanie kodu - a osobom które nie mają styczności z Daggerem niemal uniemożliwia.


A robienie magicznych rejestrów singletonowych nie pogarsza czytelności? XD

new ItemsRepository()


Używając libki gdzie repozytoria API generujesz za pomocą
@Mithrindil:

Plus dodatkowo wg mnie strasznie utrudnia czytanie kodu - a osobom które nie mają styczności z Daggerem niemal uniemożliwia


Nie rozumiem czemu uważasz, że DI utrudnia czytanie kodu - pozbywasz sie całych sekcji inicjalizacji poza klasę. Dostarczasz jej wszystkie skonstruowane zależności w konstruktorze (ewentualnie we wstrzykiwanych polach albo metodach, jeśli cykl życia obiektu jest poza twoim zasięgiem - np. Activity, Fragment).

DI + przestrzeganie reguły pojedynczej odpowiedzialności umożliwia Ci tworzyć