Wzorzec projektowy Iterator to jeden z behawioralnych wzorców. Wykorzystanie Iteratora pozwala odseparować szczegóły związane z iteracją po strukturach danych od logiki biznesowej aplikacji. Więcej o korzyściach wynikających z wykorzystania Iteratora dowiesz się z najnowszego artykułu na moim blogu. Do omówienia wzorca dołączyłem również praktyczny przykład implementacji.
Wzorzec Iterator pozwala na oddzielenie procesu iteracji od iterowanej struktury danych. Zobacz co to daje i jak wykorzystać go w praktyce!
https://devszczepaniak.pl/wzorzec-projektowy-iterator/Tylko że te wbudowane kolekcje w wielu językach i tak używają iteratora, więc moim zdaniem artykuł od @elszczepano jest nadal wartościowy.
Wzorzec projektowy Null Object znajdzie zastosowanie w miejscach, gdzie oczekujemy, że dany fragment kodu zwróci oczekiwany obiekt lub null. Null Object pozwala tworzyć kod bez konieczności obsługi nulli, co często może istotnie zwiększyć przejrzystość kodu. Jednak jego zastosowanie wiąże się z dodatkowymi klasami w kodzie. O tym, jak wykorzystać Null Object w praktyce, kiedy warto go wykorzystać, a kiedy niekoniecznie jest to dobry pomysł, przeczytasz w najnowszym artykule na moim blogu
Null Object może pomóc w wyeliminowaniu obsługi wartości null i dodatkowych instrukcji warunkowych. Sprawdź, kiedy warto go wykorzystać!
https://devszczepaniak.pl/wzorzec-projektowy-null-object/IMO średni przypadek. Jak dla mnie Null object ma sens dla interfejsów z metodami zwracające void
np. sendNotifcation
, gdzie Null Object nic nie zrobi. Jeśli wzorce mają służyć głównie dla komunikacji to szczerze zdziwiłbym się gdybym zobaczył coś się nazywa Null Object, gdzie jest jakaś logika
W aplikacjach, gdzie tworzone są kosztowne obiekty lub chcemy ograniczyć ich tworzenie, przydać się może wzorzec projektowy Object Pool. Omówienie wzorca znajdziesz w najnowszym artykule na moim blogu. W artykule dowiesz się, jak działa ten wzorzec, poznasz jego charakterystykę, przykładowe zastosowania i przykładową implementację. Omawiam również potencjalne problemy, jakie można napotkać w trakcie implementacji.
Object Pool to wzorzec projektowy, który pomoże Ci ograniczyć konstruowanie kosztownych obiektów. Sprawdź, jak możesz go wykorzystać!
https://devszczepaniak.pl/wzorzec-projektowy-object-pool/Wzorzec projektowy Flyweight pozwala na współdzielenie danych między obiektami, redukując ilość zużytej pamięci przez aplikację. Z najnowszego artykułu na moim blogu dowiesz się, jakie są założenia wzorca Flyweight oraz kiedy warto z niego skorzystać. Przygotowałem również przykładową aplikację implementującą ten wzorzec w praktyce.
Wzorzec Pyłek (Flyweight) pozwala zoptymalizować zużycie pamięci przez współdzielenie danych. Sprawdź jak wykorzystać go w praktyce!
https://devszczepaniak.pl/wzorzec-projektowy-pylek/Interpreter jest wzorcem projektowym, którego jeszcze nie miałem okazji wykorzystać w praktyce. Patrząc na jego specyfikę, raczej nieprędko się to zmieni. W najnowszym artykule na moim blogu dowiesz się, kiedy potencjalnie można by wykorzystać Interpreter. Dowiesz się też, dlaczego Interpreter jest tak trudnym w zastosowaniu wzorcem i o czym nie wspomniał Gang of Four w jego charakterystyce.
Interpreter w teorii jest przydatnym wzorcem. Jednak nigdy nie widziałem jego implementacji w praktyce. Dowiedz się w artykule dlaczego.
https://devszczepaniak.pl/wzorzec-projektowy-interpreter/@slsy no ale jeżeli robisz ewaluacje podczas parsowania to masz w sumie (parser+interpreter) trochę, czy nie? Dodatkowo możesz pominąć AST, ale czy nie daje ci to jakiejś modularności/przenaszalności, jakbyś chciał robić jakieś optymalizacje na tym AST i wynieść ten kod z parsera Przykładowo nikt nie przegląda AST danego regexa (xd)
czy aby na pewno nie chcesz zrobić sobie jakiejś wizualizacji? może nie przy regexie akurat, ale jakieś control flow graphy itd
@WeiXiao: wybacz, trochę się zagmatwałem i mam tak często z wzorcami. Z tego co rozumiem to interpreter opiera się na tym, że jest AST, parser tworzy AST, klienci je konsumują np. generują kod binarny albo robią wizualizację. Fajnie, tylko jaka jest wartość z wprowadzania takiego pojęcia
Według https://en.wikipedia.org/wiki/Chomsky_hierarchy możemy przedstawić języki jako:
Ten izomorfizm fajnie działa, bo zarówno jak klasy języków tak te struktury danych są hierarchicznie powiązane i tak jak każda lista jest drzewem tak każdy język regularny jest bezkontekstowy. Niestety mamy już design pattern pozwalający na zaimplementowanie tych dwóch przypadków i jest to kompozyt
Tak więc nie widzę na wprowadzanie takiego pojęcia jak interpreter
, bo kompozyt
jest IMO prostszy do zrozumienia i bardziej ogólny. Jedyne co mi przychodzi do głowy to fakt, że języki bezkontekstowe są bardzo popularne (wszystkie języki programowania takie są/chcą być) i ktoś uznał, że warto ten szczególny przypadek jakoś nazwać inaczej. Osobny pattern na każdy możliwą kategorię rekursywnej struktury danych jest imo bezcelowy i tylko wprowadza chaos
Wzorzec projektowy Most (Bridge) pozwala na oddzielenie abstrakcji od jej implementacji, umożliwiając ich niezależny rozwój i zmniejszając coupling w systemie. Pozwala to tworzyć kod zgodny z SRP i OCP, co pomaga utrzymać go bardziej elastycznym i skalowalnym. W najnowszym artykule na blogu wyjaśniam, kiedy warto wykorzystać wzorzec Most. Na praktycznym przykładzie pokażę Ci też jak go zaimplementować w praktyce:
Wzorzec Most pozwala na oddzielenie abstrakcji od jej implementacji, umożliwiając ich niezależny rozwój i zmniejszając coupling w systemie.
https://devszczepaniak.pl/wzorzec-projektowy-most/
Szkoda strzępić ryja na iterator, rozmowa o tym miała sens, gdy języki nie miały wbudowanych iterowalnych kolekcji i struktur językowych do ich obsługi, czyli w czasach C.