Wpis z mikrobloga

@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ą potrzebne


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

EDIT 2:

Największym chyba niezrozumieniem konceptu zależności jest stawianie interfejsu w klasach,
@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ś
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
@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
@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 jest błędna.


Zainteresowałeś mnie. Pokażesz mi przykład?

Fowlera poleciłem po przeczytaniu, że VM w MVVM mógłby być
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.
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 ( ͡° ͜ʖ ͡°)
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
@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 omijam
via Wykop Mobilny (Android)
  • 0
@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.
@MQs: Misiaczku, dwie kwestie :
- 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 słowo.