[szkok]

czym konkretnie jest ,,dependency injection", to wstrzykiwanie zależności to w praktyce łączenie ze sobą beans'ów (np. poprzez konstruktor)?
czy picrel to dobry przykład na DI?
#java #spring

[Karatte]

@szkok: definicji w xmlach nikt nie widział od 2013 roku, we to zmień na adnotacje

[szkok]

@Karatte: chlop z tutoriala mówił ze jest nadal czesto używane xd dzięki za rade

[mccloud]

@szkok czas zmienić tutorial na nowszy. :p

[franciss]

@szkok: w mocno potocznym języku tak to można zdefiniować: jeśli klaska definiuje jakich będzie potrzebowała zależności, ale nie mówi skąd je wziąć, to dependency injection jest poskładaniem tego w całość tak, żeby klaska te zależności dostała.

Beany springowe to tylko jedna implementacja DI, a załączony obrazek jest niezłym przykładem. TrackCoach definiuje że potrzebuje jakiegoś serwisu, a ty mu go dostarczasz nie w ramach implementacji TrackCoach tylko w innym, zewnętrznym miejscu.

Najprostsze

[szkok]

@franciss: dziękuje za ten komentarz, potrzebowałem go bardzo乁(♥ ʖ̯♥)ㄏ

[Myzreal]

@szkok: https://rskupnik.github.io/dependency-injection-in-pet-project-dagger2

[franciss]

@szkok: zerknąłem na to co @Myzreal podrzucił i wydaje mi się, że w artykule nieco pomięszane są koncepty Dependency Incjection oraz Inversion of Control Container.

Dependency Injection jest bardzo prostym wzorcem, definiujesz co klasa potrzebuje, a nie jak to dostać (stąd rodzaje: wstrzykiwanie przez konstruktor, setter itp.). Nie ma tu w ogóle mowy o zarządzaniu tymi zależnościami: w jaki sposób są tworzone, kto nimi zarządza (programista, framework, czy cokolwiek innego).

Inversion

[Myzreal]

@franciss: Nope, Inversion of Control (bez container) to właśnie ten wzorzec który opisałeś w drugim akapicie a Dependency Injection to jeden ze sposobów jego realizacji

[franciss]

@szkok
nie ma nic złego w definicjalch beanów XMLu, nawet jeśli obecnie są przeżytkiem. Według mnie, na poczatek zabawy ze springiem są nawet lepszym pomysłem niż adnotacje, bo używając adnotacji wprowadzasz magię, która ukrywa jak pod spodem wszystko się ze sobą łączy.

[franciss]

@Myzreal:

The basic principle is that instead of managing dependencies between components in your code by yourself, you use a single container to resolve those for you and inject the required dependencies where you want them.

W artykule to jest podane jako definicja DI. To nie jest definicja DI, tylko IoCContainer. Do DI nie potrzeba żadnego pojednyczego kontenera na zależności. Oraz dalej:

the DI library will inject the dependencies into those

[radar42]

@szkok a imię tego chłopa to pewnie Rajesh?

[PaaD]

@szkok: DI (od Dependency Injection) to jeden sposobów zasady Dependency Inversion, która żeby było śmieszniej ma taki sam skrót: DI ( ͡° ͜ʖ ͡°), która jest po prostu D z solida.

XML nie przeszkadza w zrozumieniu na czym to wszystko polega, w zasadzie poznanie tego w niczym nie przeszkodzi, a może nawet będzie potem łatwiej zrozumieć na czym polegają pozostałe dwa rodzaje konfiguracji springowych (opartych na adnotacjach

[Yeboy]

@PaaD: Ba, dodam imo coś jeszcze. Używając samych adnotacji, możesz się zdeczka zapuścić w maliny i wpaść w pętle zależności, której Spring naturalnie nie będzie w stanie ogarnąć. Przy małych projekcikach to luz, łatwo ogarnąć (choć dla początkujących w Springu i to może być problematyczne), ale wbijając się w jakiś większy projekt możesz już mieć zonka. ;)
Dlatego imo nauka na XMLu może być całkiem owocna, choć w dłuższej perspektywie cieszę