Czy da się uniknać DI?

Odpowiedz Nowy wątek
2018-11-13 00:57
0

Czy ktoś może mi odpowiedzieć na pytanie?
How do you keep your classes of functions testable with dependencies which have side effects without DI?

Ostatnio zastanawiałem się nad projektowaniem aplikacji w ten sposób aby uniknąć DI, ale nie mogę znaleźć odpowiedzi na pytanie powyżej.

Pozostało 580 znaków

2018-11-13 00:59
0

Uniknąć DI czy uniknąć kontenera DI?


"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.
można by spróbować też uniknąć side-effectów. - LukeJL 2018-11-16 19:24
Kontenera IOC, który używa DI - ._. 2018-11-18 20:13

Pozostało 580 znaków

2018-11-13 01:09
16

Bez DI testowalność będzie słaba, ale do DI nie trzeba żadnych frameworków/ bibliotek/ kontenerów/ etc (nawet własnych). Do DI wystarczy słówko new i przekazywanie zależności przez konstruktor.

Jeśli nie wstrzykujesz klasie zależności to ona musi zadbać o nie sama, czyli stworzyć je na podstawie globalnej konfiguracji bądź zdobyć z jakiegoś globalnie dostępnego miejsca. To prowadzi do utraty izolacji testów - każdy test musi poczekać aż zakończą się wcześniejsze (tzn testy muszą być jednowątkowe), by móc poprzestawiać globalny stan na potrzeby testowania. Takie cudowanie jest kiepskim pomysłem, bo można się pogubić w manipulowaniu tym globalnym stanem.


"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 2x, ostatnio: Wibowit, 2018-11-13 01:13

Pozostało 580 znaków

2018-11-13 03:40
4
InterruptedException napisał(a):

Ostatnio zastanawiałem się nad projektowaniem aplikacji w ten sposób aby uniknąć DI, ale nie mogę znaleźć odpowiedzi na pytanie powyżej.

Przy takim podejściu nie powinno się używać słowa "projektowanie".


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Dobre :-| - ._. 2018-11-18 20:24
Możesz rozwinąć dlaczego uważasz, że to złe słowo? - InterruptedException 2018-11-20 01:03

Pozostało 580 znaków

2018-11-13 08:28
2

Da się uniknąć, trzeba mieć tylko jednego dobrego zawodnika który będzie ratował projekt.
Przykład: https://denisa1956.files.wordpress.com/2007/09/dsc01395.jpg
Inne pomysły: https://blog.codinghorror.com[...]ther-architectural-disasters/


Szacuje się, że w Polsce brakuje 50 tys. programistów

Pozostało 580 znaków

2018-11-16 19:16
1

How do you keep your classes of functions testable with dependencies which have side effects without DI?

Przychodzi mi na mysł jakiś monkey patching zależności czy podmianki modułów (tak, żeby zamiast normalnych modułów importował zmockowaną zależność), ale nie są to eleganckie sposoby. To raczej w sytuacjach, kiedy miałbyś jakiś legacy kod, który ciężko byłoby jakkolwiek ruszyć i jedynym sposobem na testowanie byłaby ww. partyzantka.

Ew. mógłbyś niczego nie mockować, ale zrobić po prostu test integracyjny. Pewnie nawet lepiej byłoby niż zabawy w mockowanie (które mają to do siebie, że nie są realistyczne).

Natomiast jeśli to twój kod - to kurczę, czemu nie użyć DI? Szczególnie, że tak jak @Wibowit wspomniał - to po prostu przekazywanie zależności przez konstruktor (albo wprost do danej funkcji jako parametr).

Ludzie za duży engineering robią z tego całego DI, a ta cała koncepcja jest prosta jak drut.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
edytowany 2x, ostatnio: LukeJL, 2018-11-16 19:19

Pozostało 580 znaków

2018-11-16 20:17
6

Pytanie w tym stylu kojarzy mi się tylko z tymi idiotycznymi pytaniami początkujacych z serii chciałbym napisać XYZ ale bez uzycia klas (albo innej konstrukcji języka). Takie rzeczy są po to żeby ułatwić życie a nie je utrudnić :) Niestety są ludzie oporni na wiedzę którzy wolą umieć jak najmniej.

Odpowiedź: da się. Da sie też pisać kod bez znaków nowej linii, albo stosując tylko jednoliterowe identyfikatory. Ale to niestety klasyczny przykład na:

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
Wg mnie to bardzo ciekawe pytania, często prowadzące do niebanalnych i interesujących wniosków. - InterruptedException 2018-11-20 01:02

Pozostało 580 znaków

2018-11-17 00:31
1

Najprościej patchować na poziomie kodu źródłowego, jakiś PowerMock modyfikujący klasy binarnie w Javie, Moles/Fakes w dotnecie, w językach dynamicznych jeszcze prościej podmienić implementację obiektu w trakcie. W C/C++ można kombinować nagłówkami, co w gruncie rzeczy jest koncepcyjnie tym samym.

Inne podejście: jeżeli nie wstrzykniesz mocków z zewnątrz, to możesz je zrobić od środka, czyli klasa sama sprawdza, w jakim trybie działa (mock czy produkcja) i w zależności od tego robi coś innego. Pewnie dałoby się to ładnie opakować aspektami, dodać service locator i mieć w miarę poukrywane przełączanie implementacji. Przy odrobinie magii da się nawet równolegle odpalać testy, na przykład przez przepychanie ustawień thread localami.

Jeszcze innym podejściem jest opakowanie zmian stanu (side effect) w zdarzenia, a potem w testach można podmieniać infrastrukturę i gotowe. Czysto teoretycznie każde wywołanie metody można interpretować jako wysłanie wiadomości i czekanie na odpowiedź, możemy zrobić to explicite i dodać mockowanie na poziomie infrastruktury transportującej wiadomości.

Pozostało 580 znaków

2018-11-18 19:51
._.
0

Jak to mają side efect, niby dlaczego mają mieć side effects. Jak zależności mają side effects to powinno się użyć np. Assercji z "Design By Contract" jeśli oczywiście nie można tego załatwić interfejsem lub inaczej i nie ma to nic wspólnego z DI w testowaniu. Jakieś idiotyczne pytanie...

A niby skont mam wiedzieć, czy ta klasa w ogóle potrzebuje DI, może to nie jest zależność "zewnętrzna"?

Tylko nie mów mi, że to pytanie rekrutacyjne.

Najprościej patchować na poziomie kodu źródłowego, jakiś PowerMock modyfikujący klasy binarnie w Javie, Moles/Fakes w dotnecie, w językach dynamicznych jeszcze prościej podmienić implementację obiektu w trakcie. W C/C++ można kombinować nagłówkami, co w gruncie rzeczy jest koncepcyjnie tym samym.

W .Net możesz użyć nieograniczonego frameworka izolacji, który bazuje na Api profilera - opakowań wokół CLR.

Możesz użyć innego sposobu decoupling'u np. Event'ów.

edytowany 1x, ostatnio: ._., 2018-11-18 19:59

Pozostało 580 znaków

2018-11-20 01:01
0

Dzięki za opinie. Przemyślałem temat i przepraszam z góry za niepoprawnie skonstruowane pytanie. Chyba rozbudziło więcej wątpilwości niz powinno.

Generalnie wyjść widzę kilka, przynajmniej tak je widzę:

  1. Używanie DI jako standardowej drogi implementacji IoC.
  2. Mockowanie dużej ilości zależności w testach, bardzo brzydkie rozwiązanie.
  3. Przechylenie się jak najbardziej w kierunku funkcyjnego podejścia. Wtedy nie ma potrzeby żadnego obsługowania side effectów aplikacji. Monady zamiast DI. Generalnie temat bardzo popularny widzę.
    https://earldouglas.com/posts/itof/di-to-reader.html i ku temu będę się składniał.

Pozostało 580 znaków

2018-11-20 05:36
._.
0
InterruptedException napisał(a):

Dzięki za opinie. Przemyślałem temat i przepraszam z góry za niepoprawnie skonstruowane pytanie. Chyba rozbudziło więcej wątpilwości niz powinno.

Generalnie wyjść widzę kilka, przynajmniej tak je widzę:

  1. Używanie DI jako standardowej drogi implementacji IoC.
  2. Mockowanie dużej ilości zależności w testach, bardzo brzydkie rozwiązanie.
  3. Przechylenie się jak najbardziej w kierunku funkcyjnego podejścia. Wtedy nie ma potrzeby żadnego obsługowania side effectów aplikacji. Monady zamiast DI. Generalnie temat bardzo popularny widzę.
    https://earldouglas.com/posts/itof/di-to-reader.html i ku temu będę się składniał.

1,2 to dalej DI, wiec nie rozumiem jak to się ma do twojego pytanie.

3

Monady? widzę, że @jarekr000000 dobrze hype pompuje, drugi cqrs się robi. :-|

Monada ma inny charakter niż DI. Monadą "nie wstrzykniesz" wartości.

Nie wiem co jest dla ciebie tym side effects.

Wiec ustalmy.

Null nie musi być uznawany za side effects, nie widzę żadnego side effect'u w tym, że coś może być puste. Wyjątek też nie zawsze musi być uznawany za side effect. Wyjątek najczęściej jest, rzucany właśnie po to, żeby uniknąć side effects, w tym celu przerywa się akcje aplikacji wyjątkiem. Jest taki fajny przykład z mieszaniem farb, który tłumaczy side effect, zdaje się, że w książce Evansa.

Nienawidzę jak ktoś mówi mockowanie, zwłaszcza że 93% procent tych ludzi nie rozumie czym mock jest.

edytowany 3x, ostatnio: ._., 2018-11-20 05:53

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