[Kicer86]

Przeglądnąłem sobie kilka frameworków dependency injection dla #cpp w nadziei, że pomogą mi się uporać z pewnym problemem. No i powiem szczerze, że nie rozumiem jaki problem te frameworki rozwiązują.

z tego co widzę, to pozwalają na zapisanie zamiast (na bazie boost.di):

A a

B b

C c(a, b)

czegoś takiego:

auto a = 'jak ktoś bedzie chciał 'A' to daj mu 'A' a jak będzie chciał 'B' to daj mu 'B'

a.zbuduj C
jaki tu jest zysk?
#programowanie #programista15k

[C.....y]

@Kicer86: Nie znam specyfiki cepa, ale framework do DI pozwala na realizację wzorca Inversion of Control i rozwiązuje przede wszystkim problemy mocnych powiązań między klasami oraz tworzeniem obiektów z dużą listą zależności przekazywanych z zewnątrz. To, co pokazuje Twój przykład, to raczej stosowanie kontenera jako service locatora, co może wywołać kilka uniesionych brwi, jako, że jest to raczej antywzorzec

[tell_me_more]

@Kicer86: dependency injection pozwala np. ograniczyć binarne zależności między komponentami. Napisz czego konkretnie potrzebujesz.

[passage]

@Kicer86: @Czesiowcy: @tell_me_more: i przede wszystkim zajebiście ułatwia pisanie testów jednostkowych.

[C.....y]

@passage: To trochę efekt uboczny albo synergia, nie problem rozwiązywany przez frameworki do DI. Zwróć uwagę na to, że stosowanie kontenera DI w postaci zaprezentowanej przez OPa raczej nie ułatwi Ci życia z testami.

[Kicer86]

@tell_me_more, @Czesiowcy, @passage:
generalnie wiem do czego jest DI, natomiast problem który mam jest taki, że posiadając hierarchię klas, klasa 'główna' musi przyjmować interfejsy, które jej wprost są niepotrzebne, ale które są oczekiwane przez jej 'dzieci'. Teoretycznie mógłbym taką hierarchię klas budować wstrzykując obiekty 'dzieci' do klasy 'głównej' jednakże nie zawsze ma to sens.

[tell_me_more]

@Kicer86: podziel na kilka klas? Ciężko stwierdzić bez konkretnego przykładu, czasem lepsze jest dziedziczenie, czasem kompozycja, czasem podział. Może część funkcjonalności powinno być w klasie-akumulatorze przekazywanej jako parametr, a reszta może być w hierarchii z jednym interfejsem?

Ludzie jak dostaną młotek (DI) to zaczynają traktować wszystko jako gwóźdź, czasem DI jest niepotrzebne :)

[Kicer86]

To, co pokazuje Twój przykład, to raczej stosowanie kontenera jako service locatora, co może wywołać kilka uniesionych brwi, jako, że jest to raczej antywzorzec

@Czesiowcy: generalnie masz rację, natomiast w przypadku boost.di (i innych) obiekt odpowiedzialny za dependencje jest 'lokalny', więc to złe nie jest, tylko że ja nie do końca widzę zastosowanie (chyba, że ma się jakąś mega złożoną konstrukcję do postawienia).

[C.....y]

@Kicer86: Nie znam Twojego konkretnego przykładu, ale w takim razie zależności powinny być przekazywane bezpośrednio do obiektów, które ich oczekują. Jeśli jest z tym problem, bo powinny być tworzone dynamicznie w trakcie działania programu, nie na etapie odpalania/kompilacji, to dobrym sposobem (jeśli rzeczywiście chcesz stosować DI) jest używanie jako zależności fabryk do takich obiektów. Fabryka jasno definiuje to, co tworzy poprzez DI, i uniemożliwia wyciąganie wszystkiego jak leci.

[Kicer86]

podziel na kilka klas? Ciężko stwierdzić bez konkretnego przykładu, czasem lepsze jest dziedziczenie, czasem kompozycja, czasem podział. Może część funkcjonalności powinno być w klasie-akumulatorze przekazywanej jako parametr, a reszta może być w hierarchii z jednym interfejsem?

@tell_me_more: jeśli myślę o tym samym co Ty, to używam kilku takich akumulatorów (grupujących tematycznie interfejsy). Tylko własnie po raz kolejny otarłem się o sytuację, że gdzieś na dole hierarchii chciałem użyć nowego obiektu,

[C.....y]

@Kicer86: To jest dosyć niestety dosyć częsty problem w przypadku kodu, który nie był od początku pisany z użyciem kontenera DI i potem trzeba robić przepychanie zależności ręcznie, w dół hierarchii zależności ( ͡° ʖ̯ ͡°)

[Saly]

@Kicer86: frameworki DI przydają się głównie w przypadkach, jak masz źle zaprojektowany kod, wtedy takie spinanie zależności poprzez framework sprawia, że jest dużo czytelniej. Inne zastosowania to np. użycie innych gównianych frameworków np. w javie użycie servletów sprawia, że w zasadzie nie masz maina. Taka struktura kodu wymusza na tobie użycie frameworka DI, w innym przypadku możesz polegać tylko na tworzeniu globalnych singletonów, co jest jeszcze gorsze, albo pisanie własnej