Dependency injection - templates + closures

0

Panowie - jako php'owiec wyjatkowo mam cos do zrobienia w c++. Interesuje mnie implementacja DI przy uzyciu templates oraz closures. Czy ktos kiedys/cos/gdzies mial z tym do czynienia ?

1

A nie możesz po prostu wstrzyknąć jak człowiek, przez konstruktor?

0

Nie. RAZ bo testy, DWA bo lazy loading.

1

W jaki sposób wstrzykiwanie przez konstruktor miałoby przeszkadzać w testowaniu bądź leniwym ładowaniu?

0

Oczywiscie ze nie przeszkadza, ale sposob ktory masz na mysli sprawia ze szlak trafia "loose coupling" co rowniez ma swoje odwzierciedlenie w jakosci kodu testow. I tu wlasnie pojawiaja sie DI kontentery oparte o closures.

http://programmaticallyspeaking.blogspot.be/2010/04/beautiful-dependency-injection-in-c.html
http://vladris.com/blog/2016/07/06/dependency-injection-in-c.html

Nie jest moim zamiarem prowadzenie dyskusji o wyzszosci swia Bozego Narodzenia nad swietami Wielkanocy, po prostu chce zaimplementowac DI w oparciu o kontener i inversion of controll. Mozesz miec na ten temat swoje zdanie i szanuje to ale w takim przypadku bedzie ono zupelnie bezuzyteczne dla mnie.

1

Co? Wydaje mi się, że nie masz pojęcia, o czym mówisz.

W jaki sposób DI realizowane przez wstrzykiwanie przez konstruktor jest wbrew dobrym praktykom?

0

To zalezy w jaki sposob dokonuje sie tego wstrzykniecia, zerknij na linki, ktore wstawilem powyzej.
A tutaj przyklad (co prawda w php ale dla was goscie od c++ nie bedzie stanowic problemu) tego czego chcialbym uniknac w przypdku DI rozumianym przez Wibowit.

https://code.tutsplus.com/tutorials/dependency-injection-in-php--net-28146

Zatem cytujac Wibowita :> A nie możesz po prostu wstrzyknąć jak człowiek, przez konstruktor?

Problemem nie jest "wstrzyknac" ale "po prostu"

0

Chłopie ja cie nie łapie. Przytaczasz DI z przed c++11 gdzie autora boli zarządzanie pamięcią, odpowiadam zawsze będzie w c++ boleć teraz trochę mniej niż kiedyś. Tak jak przesadzisz z DI to będziesz robił mega konstruktory, ale z każdą techniką można przesadzić!
Dwa co masz za problemy w UT używać mocków? A w testach wyższych rzędów i tak korzystasz z kompletnych modułów.

0
revcorey napisał(a):

Chłopie ja cie nie łapie. Przytaczasz DI z przed c++11 gdzie autora boli zarządzanie pamięcią, odpowiadam zawsze będzie w c++ boleć teraz trochę mniej niż kiedyś. Tak jak przesadzisz z DI to będziesz robił mega konstruktory, ale z każdą techniką można przesadzić!
Dwa co masz za problemy w UT używać mocków? A w testach wyższych rzędów i tak korzystasz z kompletnych modułów.

A to dasz rade zlapac ?

https://code.tutsplus.com/tutorials/d[...]y-injection-in-php--net-28146

1

Na początku przyznam się, że dynamicznego zarządzania pamięci w C/ C++/ Ruście nie robiłem - moje programy zwykle alokowały potrzebną pamięć na starcie i dealokowały na końcu. Odniosę się więc o artykułu o PHP (w którym to pisałem jeszcze mniej niż w C/ C++/ Ruście, ale artykuł jest bardziej o ogólnej idei niż o PHPie samym w sobie). Przy czym w Ruście kompilator sprawdza mi czasy życia obiektów i referencji, więc nie muszę się tym przejmować dopóki nie dostanę błędów kompilacji (a wtedy robię refaktor i znowu jest spoko).

Constantic napisał(a):

To zalezy w jaki sposob dokonuje sie tego wstrzykniecia, zerknij na linki, ktore wstawilem powyzej.
A tutaj przyklad (co prawda w php ale dla was goscie od c++ nie bedzie stanowic problemu) tego czego chcialbym uniknac w przypdku DI rozumianym przez Wibowit.
artykuł

I tu pojawia się często powtarzany mit:

Messy Start-up Code
So, you've begun passing your dependencies in your class constructors, but as the project grows, you end up with many levels of objects that must be created when your application starts.
Depending on your application's size, creating all objects to launch your application can be a very long process and hurt your application's performance (as well as result in messy code). Here's an example:
(...)
This start-up code is rather small. If you build a large application, your start-up code can become much heavier than this. Needless to say, this results in some difficult to maintain code.

Uwaga, uwaga, niespodzianka! Ten kod, który tworzy explicite graf zależności można podzielić na metody, klasy, paczki, etc (co tam sobie używacie do organizacji kodu). Ja tak dokładnie zrobiłem i to z kodem, który wcześniej był oparty na wstrzykiwaniu zależności za pomocą Google Guice. W Guice jest taki koncept jak moduły, czyli chodzi o to, że reguły do tworzenia grafu zależności można pogrupować w oddzielnych klasach. Tyle, że nie trzeba zaprzęgać kontenera DI, by sobie podzielić tworzenie grafu zależności na klasy. Wywaliłem Guice'a zastępując go ręcznym wstrzykiwaniem zależności, a następnie ten kod z ręcznym wstrzykiwaniem zależności podzieliłem na klasy. Zostałem z podobną ilością kodu, ale za to graf jest tworzony explicite, więc można w nim normalnie nawigować tak jak po całej reszcie kodu.

0

A to dasz rade zlapac ?

dzięki stary, bez ciebie bym tego nie wiedział… gdyby nie to że pracuję z ogromnym kodem z DI w którym ta technika szkodzi to bym nie wiedział. Przeczytaj sobie jeszcze z trzy razy mojego posta. To może zrozumiesz. DI NIE JEST ZŁE, ALE JAK KAŻDA TECHNIKA NADUŻYWANY PROWADZI DO PROBLEMÓW. Zastanów się nad swoją architekturą po prostu może?

0

Wibowit,

Bardzo Ci dziekuje, za za Twoja wypowiedz.

Recovery,

Swego czasu (mam na mysli web developerke) forumweb.pl bylo wspanialym miejscem, ktore laczylo ludzi bo Ci, ktorzy cierpieli na niedostatek wiedzy mogli liczyc na przychylne traktowanie przez tych, ktorzy ta wiedza dysponowali. W tej chwili forum o ktorym wspomnialem jest niemal martwe biorac pod uwage aktywnosc jego uzytkownikow. Przyczyna sa ludzie, a dokladniej Ci ktorych wsparcia sie oczekuje, ktorzy zapomnieli iz takie miejsca - istnieja tylko dzieki "glupcom" zadajacym "glupie" pytania, lub heretykom majacym odmienne zdanie od wiekszosci.
Ja zwrocilem sie tutaj o wsparcie w implementacji konkretnych rozwiazan i jedyna rzecz z jaka sie spotykam to natychmiastowa "poniewierka". Moglbym sie wiele rzeczy nauczyc od Ciebie, wiele dowiedziec bo mimo wszystko zakladam, ze Twoja obecnosc tutaj nie ma na celu wylacznie nieustannego rozbudowywania wlasnego ego, ale zawiodles na calej linii bo mnie po prostu sploszyles.
Dzieki panowie, ale milo nie bylo ...

1

Nie wiem czy dobrze rozumiem problem, o którym tutaj rozmawiacie, ale @Constantic czy chodzi Ci o napisanie klasy generycznej do której metodę tworzącą obiekt w jakimś tam określonym stanie wstrzykujesz przez konstruktor, a jego tworzenie odraczasz do momentu pierwszego użycia? Sorry, za ten łopatologiczny język ale próbuję przy okazji zrozumieć o czym mówicie.

Jeśli tak, to na myśl przychodzą mi na szybko takowe rozwiązania:
https://4programmers.net/Pastebin/8755
https://4programmers.net/Pastebin/8756

Jeśli nie to sorry za offtop.

0

a) Czy podałeś coś więcej o swojej architekturze czy też aplikacji? Odpowiedź: Nie
b) Z góry stwierdziłeś że DI jest złe, rzuciłeś na to linki
c) Co ja zrobiłem powiedziałem że DI nie jest złe samo w sobie a jego nadużywanie moze powodować problemy, zapytałem też jaki masz problem z mockami czyli testami w UT. Tego się nie dowiedziałem dostałem za to "ciekawą" odpowiedź.

Jeśli ktoś chce pomocy wypadało by po prostu napisać mam problem z A i B bo taki mam zamysł architektury. A tymczasem dostaję linki do czyiś kodów. Dla mnie nie ma problemu w rozmowie o samym problemie kiedy go przedstawisz, tymczasem schowałeś się za linkami. Ja nie jestem jasnowidzem i nie wiem co masz za zamysł w głowie. Przy danym problemie coś się może sprawdzić albo nie i trzeba podejść do sprawy indywidualnie.

0

Ketam,

Dzieki za wypowiedz.Tytulem wstepu vs 2017 zainstalowalem jakies 3 dni temu i mniej wiecej tyle samo czasu trwa moja przygoda z c++ tyle tytulem wstepu, bo najlepiej od razu wyjasnic, ze obca mi jest specyfika tego jezyka i na wszstko (co jest raczej oczywiste) patrze z perspektywy php. Otoz na moim podworku wykorzytuje kontenery ktore maja mniej wykorzytuja tablice closures mniej wiecej takiej postaci:

    $c['logger'] => function ($c)
    {
        $settings = $c['settings'];
        $logger = new Monolog\Logger($settings['logger']['name']);
        $logger->pushProcessor(new Monolog\Processor\UidProcessor());
        $logger->pushHandler(new Monolog\Handler\StreamHandler($settings['logger']['path'], Monolog\Logger::DEBUG));
        return $logger;
    }

Oczywiscie jest w rzeczywistosc jest to odrobine bardziej zlozone bo sam kontener jest obiektem a tablica jego atrybutem ale chodzi o uproszczenie.
Zatem wywolanie przez router kontrollera:

$controller = $c['controller'];

Powoduje kaskadowa injekcje poszczeglolnych elementow do odpowiednich konstruktorow (repozytorium, serwis itp). W przypadku klas ktorych wylowanie jest opcjonalne odpala sie ponownie kontener. Jesli chodzi o c++ chcialbym zrobic rzecz analogiczna. Oczywiscie kontenery w PHP wykorzystuja autowiring zatem takie reczne deklarowanie elementow injekcji nawet nie wystepuje, ale powtarzam chodzi mi o prosta do wykonania w c++ rzecz.

0
revcorey napisał(a):

a) Czy podałeś coś więcej o swojej architekturze czy też aplikacji? Odpowiedź: Nie
b) Z góry stwierdziłeś że DI jest złe, rzuciłeś na to linki
c) Co ja zrobiłem powiedziałem że DI nie jest złe samo w sobie a jego nadużywanie moze powodować problemy, zapytałem też jaki masz problem z mockami czyli testami w UT. Tego się nie dowiedziałem dostałem za to "ciekawą" odpowiedź.

Jeśli ktoś chce pomocy wypadało by po prostu napisać mam problem z A i B bo taki mam zamysł architektury. A tymczasem dostaję linki do czyiś kodów. Dla mnie nie ma problemu w rozmowie o samym problemie kiedy go przedstawisz, tymczasem schowałeś się za linkami. Ja nie jestem jasnowidzem i nie wiem co masz za zamysł w głowie. Przy danym problemie coś się może sprawdzić albo nie i trzeba podejść do sprawy indywidualnie.

a) nikt mnie o to nie zapytal, poza tym nie mam problemu z architektura aplikacji, a jedynie z implementacja kontenera DI w oparciu o IC, ale nawet nie mialem szansy tego wyjasnic bo nikogo to nie interesowalo
b) nigdy nie twierdzilem ze DI jest zle - zgadzam sie jedynie z pewnymi zastrzezeniami co do sposobu jego implementacji.
c) nie szukam wsparcia w rozwiazaniu problemu z mockami ani testami.

Napislamem wyraznie jakiej pomocy oczekuje, ale moge powtorzyc : implementacja DI w oparciu o templates i closures. Gdybs mi zadal podobne pytanie w odniesieniu do php ani rodzaj ani architektura ani przyczyny dla ktorych wybierasz takie rozwiazanie nie mialyby dla mnie zadnego znaczenia.

0
ketam napisał(a):

Nie wiem czy dobrze rozumiem problem, o którym tutaj rozmawiacie, ale @Constantic czy chodzi Ci o napisanie klasy generycznej do której metodę tworzącą obiekt w jakimś tam określonym stanie wstrzykujesz przez konstruktor, a jego tworzenie odraczasz do momentu pierwszego użycia? Sorry, za ten łopatologiczny język ale próbuję przy okazji zrozumieć o czym mówicie.

Jeśli tak, to na myśl przychodzą mi na szybko takowe rozwiązania:
https://4programmers.net/Pastebin/8755
https://4programmers.net/Pastebin/8756

Jeśli nie to sorry za offtop.

ketam, DZIEKI to jest chyba cos w tym stylu.

Troche czasu mi zajela analiza, wczoraj bylo juz pozno i tak jak pisalem wczesniej c++ to nie moja bajka (nadal sie troche gubie w ciut zawilej skladni), ale z tego widze to o cos takiego mi chodzi. Mam tylko jedno pytanie dlaczego struktura a nie klasa ?

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