Aktywne Wpisy
DrCieplak +170
Śmieszne jak dzisiaj #rozowepaski mówią że nie będą się babrać w kupach dziecka, po czym kupują kota i wyjmują jego g---o z kuwety 2 razy dziennie. Dziecko mając dwa lata będzie siadać na nocnik a kolejne dwa lata później będzie się załatwiać jak dorosły, kot będzie srał do pudełka do końca życia a #p0lka która się tak brzydzi kupy dziecka będzie ten kał wybierać i to już jej
Dobra, zrobił się ruch na tagu dlatego wyjdę z propozycją, o której myślałem już jakiś czas. ( ͡° ͜ʖ ͡° )つ──☆*:・゚
Z racji tego, że zbliża się czas Świąt i Wykopaki, pomyślałem, że fajnie byłoby zorganizować spotkanie dla wszystkich chętnych, którzy biorą udział w tej zabawie.
Co powiecie na spotkanie w Poznaniu? 🍻
Może kolega od fabii
Z racji tego, że zbliża się czas Świąt i Wykopaki, pomyślałem, że fajnie byłoby zorganizować spotkanie dla wszystkich chętnych, którzy biorą udział w tej zabawie.
Co powiecie na spotkanie w Poznaniu? 🍻
Może kolega od fabii
https://blogokodzie.pl/kilka-slow-o-dependency-injection-wstrzykiwaniu-zaleznosci/
#blogokodzie #programowanie #programista15k
EDIT:
Komentarz usunięty przez moderatora
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 ( ͡° ʖ̯ ͡°)
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 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
@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 do api transformował odp. na instancje i zapisywał ją do bazy (duży potworek
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ą po to aby poszczególne elementy programu były luźno powiązane ale spójne." To zdanie właśnie powoduje sytuacje w których ktoś myśli, że lepiej walnąć gdzieś interfejs na wszelki wypadek, nie myśląc, że jest potrzebny. Zauważyłem jednak u siebie pewien nieszczęśliwy skrót myślowy - np. taki Model domenowy może być w jednym środowisku interfejsem a w drugim klasą. W tym wypadku oczywiście interfejs jest wporzo.
ad.5. Daj spokój. Jak mówi że w jego języku nie ma DI, to oczywiście ma racje. Ale to zdanie i tak jest bez sensu, bo co ma piernik
Napisał że typescript, który nadaje się do takiego tłumaczenia jak osobówka do zabrania dzieci na wycieczkę szkolna
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.
@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.
@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 ( ͡° ͜ʖ ͡°)
Ostatnio ktoś tu wrzucał "czystą Domain Driven architekturę" - widzę interfejs o nazwie mniej więcej
SqlConnectionFactoryInterface
i nie tracąc czasuWiem ż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.
- Jak nie spojrzę, nie mam pojęcia, jak związany z tematem jest Twój drugi akapit, poza tym, że chcesz brzmieć mądrze i chwalisz się, że wykrywasz oczywisty code smell. Jeśli tak, to potraktuj się pogłaskany po główce, jesteś bardzo mądry, pomimo tego, że nie wiem, czym rzeczony SqlConnectionFactoryInterface miałby być albo jaką rolę spełniał, ani w którym miejscu rzeczonej architektury się znajdował. Wierzę Ci na
1. No to ktoś będzie musiał wejść na inna stronę żeby sobie doczytać :)
2. „Tam gdzie są potrzebne”, czyli gdzie?