[Garen_eye]

Znów coś naklepałem o programowaniu.
https://blogokodzie.pl/kilka-slow-o-dependency-injection-wstrzykiwaniu-zaleznosci/

#blogokodzie #programowanie #programista15k

[alex-fortune]

@Garen_eye: troche poplynales z tym ze nie ma roznicy jak jest injectowane - tzn, to sie wszystko kwalifikuje pod dependency injection, ale na tym podobieństwo się kończy ;)

EDIT:

Może się mylę, może w przyszłości zmienię zdanie - ale moim zdaniem interfejsy najczęściej nie są

[Garen_eye]

@alex-fortune: czytaj dalej chłopak!

[alex-fortune]

@Garen_eye: przeczytalem do końca i nadal podtrzymuję powyższe punkty ;)

[Garen_eye]

@alex-fortune: dzięki za przeczytanie! Co do nierozbijania jednak niektóre patterny (jak mvvm) rozbijają.

[MikelThief]

@Garen_eye: https://www.youtube.com/watch?v=9lABk-PINxI

co za herezje. Weź tego nikomu nie wysyłaj bo cię wyśmieje. z każdym akapitem jest coraz gorzej. Mylisz koncepty, pojęcia i zastosowanie wzorców! Uncle Bob by ci lepę wypłacił jakby zobaczył że okładka jego książki stoi pod czymś takim ( ͡° ʖ̯ ͡°)

[Garen_eye]

@MikelThief: musisz mi rzucić argumentami bo inaczej się niczego nie nauczę ( ͡° ͜ʖ ͡°)

[MikelThief]

@Garen_eye: niech stracę trochę czasu i nerwów - najważniejsze:

1. Ogólny chaos (wrzucasz fragmenty kodu napisanego w jakimś języku, o którym nie wspominasz. Wydaje mi się, że to Swift. Kogoś kto nie ma pojęcia o DI wprowadza to wyłącznie w zakłopotanie.
2. Nie ma czegoś takiego jak wstrzykiwanie klasy przez pole publiczne. To nie jest wstrzykiwanie.
3. Co to znaczy że komponenty nie powinny być zależne od komponentów niższego poziomu? Czegoś w tym zdaniu

[bmLq]

Protip - w tym przypadku rozbijanie klasy na dwa jest błędem, rozbija się jedną odpowiedzialność na dwie klasy.

@alex-fortune: Nie zgodzę się do końca z tym zdaniem. Trochę oksymoron. Pierwszy przykład z brzegu:
UserImporter -> UserFactory, UserFetcher, UserSaver

UserFactory i UserFetcher w tym przypadku istnieją tylko dla UserImportera. Nie wykluczam, że w przyszłości to się może zmienić ale tak jest. Z kolei jak byś to wszystko wrzucił do importera to importer pukał by

[Garen_eye]

@MikelThief: fajnie że straciłeś dla mnie czas i nerwy, doceniam to! Ale jeszcze Cię podenerwuję.
ad.1. Dzięki za info, że wzmianka o Typescripcie na samym początku artykułu nie jest dla wszystkich widoczna.
ad.2. Jest proszę Pana. I właśnie w Swifcie i chociażby bardzo popularnym Swinject'cie. Nikt nigdzie nie napisał, że akurat ta metoda jest błędna.
ad.3. Okej, może faktycznie powinienem z zalinkowanego tam posta przekleić definicje czym są poziomy komponentów.
ad.4 "Interfejsy są

[zibizz1]

@MikelThief:
Napisał że typescript, który nadaje się do takiego tłumaczenia jak osobówka do zabrania dzieci na wycieczkę szkolna

[MikelThief]

@Garen_eye:

Wiadomo, że przez IoC bo przecież można to ze sobą utożsamić.

A w życiu! Czy słyszałeś o (anty)wzorcu ServiceLocator? To również DI. Pisząc DI w tym punkcie miałem na myśli Dependency Inversion.

ad.2. Jest proszę Pana. I właśnie w Swifcie i chociażby bardzo popularnym Swinject'cie. Nikt nigdzie nie napisał, że akurat ta metoda

[C.....y]

A z tym to juz w ogole XD powodzenia w testowaniu bez interfejsow

@alex-fortune: nie wiem, jak w Javce albo czymś pokrewnym, ale frameworki mockujące w .NET generują dynamiczne proxy nadpisujące metody wirtualne, więc technicznie rzecz biorąc, interfejsy nie są niezbędne. Czasem przypominają sztukę dla sztuki.

[alex-fortune]

jednak niektóre patterny (jak mvvm) rozbijają.

@Garen_eye: no to robia zle

@bmLq: musialbys dac lepszy obraz tego co te klasy robią, ale nawet na pierwszy rzut oka wydaje się, że mogą działać osobno.

@Czesiowcy: wiem, ale z dwojga zdecydowanie wolę używać najprostszego polimorfizmu oferowanego przez język niż bawić się w syfiaste grzebanie w bebechach klas ( ͡° ͜ʖ ͡°)

[alex-fortune]

2. Nie ma czegoś takiego jak wstrzykiwanie klasy przez pole publiczne. To nie jest wstrzykiwanie.

3. Co to znaczy że komponenty nie powinny być zależne od komponentów niższego poziomu? Czegoś w tym zdaniu brakuje.

4. Interfejsy są potrzebne, ale to już ci napisał mirek wyżej. Nie piszesz testów - faktycznie mogą być niepotrzebne. Interfejsy są po to aby poszczególne elementy programu były luźno powiązane ale spójne.

5. Jak ktoś mówi że jego język nie ma

[MQs]

@Czesiowcy: Cały system typów można określić sztuką dla sztuki. Albo się go używa po bożemu, albo jako hack (meta programowanie), albo wcale - w każdym z tych sposobów program będzie działał. Używanie ortodoksyjne ma to do siebie, że oprócz błędów pozwala wykrywać smrody (o ile się do nich nie przyzwyczaiłeś).

Ostatnio ktoś tu wrzucał "czystą Domain Driven architekturę" - widzę interfejs o nazwie mniej więcej SqlConnectionFactoryInterface i nie tracąc czasu

[zibizz1]

@Garen_eye:
Wiem że chcesz fajnie i przyjemnie jakieś tam zagadnienia ale przestań.
1. Pokazujesz najprostszy przykład wzorców, nie pokazując ich potęgi i realnego zastosowania. Nikt nie wie po co I co zyskuje, jakich problemów unika.

2. Interfejsy stosuje się tam gdzie są potrzebne. Tworzenie kodu który jest łatwo testowalny(pary jedna klasa-jeden interfejs) jeśli nie robimy testów I nie wiemy czy zrobimy jest bez sensu.

[Garen_eye]

@zibizz1: no niestety nie przestane, tak już mam.
1. No to ktoś będzie musiał wejść na inna stronę żeby sobie doczytać :)
2. „Tam gdzie są potrzebne”, czyli gdzie?

[alex-fortune]

@MQs: czemu Metaprogramowanie to hack? C++ templates to jak na moje żaden hack, co innego runtime analiza typów ( dynamic_cast tudzież instanceof w językach wyższego poziomu ) ;)