To jest 245. odcinek podcastu Porozmawiajmy o IT, w którym w cyklu rozmów z Łukaszem Drynkowskim z portalu z ogłoszeniami pracy IT SolidJobs, który mam przyjemność współtworzyć, dyskutujemy o software craftsmanship, czyli o rzemiośle programisty. 

Zapraszamy do słuchania i komentowania. A teraz życzymy Ci już miłego słuchania. 

Odpalamy! 

 

Cześć, Łukasz! 

 

Cześć, Krzysztof! 

 

Nasze kolejne spotkanie w ramach cyklu podcastu o software craftsmanship. Spotykamy się, żeby rozmawiać o rzemiośle, żeby poruszyć tematy, z którymi my jako programiści na co dzień mamy do czynienia. Nasza wcześniejsza seria podcastów, do której oczywiście też odsyłamy, dotyczyła narzędzi. Tutaj poruszamy takie tematy jak programowanie obiektowe, funkcyjne, clean code, to, kim jest inżynier rozwiązań, czy też podejście Secure by Design, więc osoby zaciekawione jak najbardziej odsyłamy do tych wcześniejszych odcinków. A dzisiaj będziemy mówić o też istotnym, jakby nie było temacie, jakim są wzorce projektowe.

Nie będziemy chcieli jednak tutaj teoretyzować i omawiać poszczególnych wzorców, nie o to tutaj nam chodzi, jest mnóstwo materiałów w sieci, gdzie można sobie właśnie tę wiedzę odszukać, natomiast będziemy chcieli się podzielić naszymi spostrzeżeniami i doświadczeniami wynikającymi właśnie z używania wzorców projektowych.

Ja tak sobie myślę, że to jest tego typu narzędzie, którym wyrządzono tyle samo dobra co zła. Nie jest to narzędzie biało-czarne, do czego na pewno będziemy dzisiaj chcieli nawiązać. Po prostu jest to narzędzie. Jakby nie było, trzeba wykorzystywać je w odpowiedni sposób.

Myślę sobie, że tutaj nieco przewrotnie może rozpoczniemy to nasze dzisiejsze spotkanie i zamiast rozpocząć od mówienia o pozytywach, to spróbujemy rozpocząć od tego, jakie są niewłaściwe użycia albo nadużycia wzorców projektowych. Od czego myślisz, Łukasz, moglibyśmy w tym temacie zacząć?

 

Myślę, że pierwszym tutaj takim ryzykiem to jest ryzyko tzw. złotego młotka, czyli fiksujemy się na czymś, co poznaliśmy właśnie i próbujemy, widzimy wszędzie gwoździe, nawet jeśli dana rzecz gwoździem nie jest i po prostu próbujemy na siłę użyć danego wzorca, czyli się po prostu podekscytowaliśmy znajomością jakiegoś wzorca.

Mogę tutaj taką historię opowiedzieć:  na studiach, pamiętam, robiliśmy z kolegą taki program typu peer-to-peer do przesyłania plików między dwoma komputerami. I pamiętam, że wzorzec command tam był. Wszędzie, gdzie się dało, to po prostu ten command, tak się tutaj na ten wzorzec command po prostu zafiksowaliśmy. Bardzo fajny wzorzec swoją drogą, ale jestem pewien, że na pewno nie zawsze, gdzie został użyty, miał sens.

I inny przykład: taki wzorzec template method. Też pamiętam właśnie, że jak go odkryłem, to o, jak fajnie można tutaj między te klasy różne zachowania wymusić, natomiast później dopiero przyszło takie otrzeźwienie, jakieś takie zrozumienie większe tematu. Też tutaj okazało się, że jednak template method używa dziedziczenia, które samo w sobie jakby nie jest antypaternem, ale nadużywanie dziedziczenia jak wiadomo już jest takim antypaternem i powoduje różnego typu problemy w trakcie programowania, w trakcie designu.

I np. taką alternatywą dla tego template method to, myślę, jest wzorzec strategii, który tutaj wtedy ma mniej tych wad. Oczywiście te użycia nie zawsze są takie same, nie zawsze można jedno zastąpić drugim, ale jak widać, są alternatywy. Nie zawsze też alternatywą musi być inny wzorzec projektowania. Czasami możemy użyć po prostu jakiegoś feature’a, który jest wbudowany w język programowania. Też te nowoczesne języki programowania, myślę, w tej chwili dużo tutaj tego, co dawały nam wzorce projektowe i tego, dlaczego te wzorce projektowe w ogóle powstały, to powstały, bo czegoś nie było w tych językach programowania, jakiejś możliwości. A już jesteśmy w 2024 roku i dużo tych wzorców projektowych jest gdzieś tam zaimplementowanych już w corze pewnych funkcji, pewnych bibliotek.

I np. taką alternatywą dla tego template method to, myślę, jest wzorzec strategii, który tutaj wtedy ma mniej tych wad. Oczywiście te użycia nie zawsze są takie same, nie zawsze można jedno zastąpić drugim, ale jak widać, są alternatywy. Nie zawsze też alternatywą musi być inny wzorzec projektowania. Czasami możemy użyć po prostu jakiegoś feature’a, który jest wbudowany w język programowania.

 

Właśnie, wiesz, niech pierwszy rzuci kamień ten, kto nie poznawszy jakiegoś wzorca projektowego, nie zaczął go używać wszędzie, bo wydawało się, że to jest tak idealne rozwiązanie, że sprawdzi się doskonale, tymczasem bardzo szybko prowadzi to do jakiegoś over engineeringu, później trudności ze zrozumieniem, co tak naprawdę artysta miał na myśli.

 

Tak, natomiast to nie jest tak, że wzorce projektowe są złe, tego też nie chcemy tutaj powiedzieć. Po prostu to jest narzędzie i musimy używać go z głową. Np. teraz, żeby dać taki kontrapunkt, uważam, że wzorce projektowe są świetnym narzędziem do tego, żeby się uczyć programować, żeby po prostu jak ktoś zaczyna swoją przygodę z kodem, to od razu jakieś takie dobre wzorce, gdzieś mu się tam te synapsy w mózgu połączą w odpowiedni sposób, na pewno więcej wśród wzorców projektowych jednak jest wzorców pozytywnych niż antywzorców.

Nawet jeśli któryś z tych tradycyjnych wzorców jest uznawany za antywzorzec, pewnie chłopiec do bicia Singleton, to jednak nie jest tak, że nie ma takiej sytuacji, gdzie ten Singleton by nie mógł być pozytywnie użyty, tak jak z Go2, niby złe, ale jednak ta jedna sytuacja na milion jest taka, że jednak ma to sens i o to właśnie chodzi, żebyśmy używali tego wszystkiego świadomie.

 

Dokładnie, powiedziałeś, że już na studiach byłeś zafascynowany przynajmniej niektórymi wzorcami projektowymi i myślę sobie, że właśnie ta prawda objawiona po części wynika z tego, że jakby wziąć dowolną listę sugerowanych książek w IT, to tam zawsze się znajdzie ta słynna pozycja od Gang of Four, Wzorce projektowe i właśnie chyba podchodzimy do tego w ten sposób, że to jest niejako księga objawiona, że tam jest prawda, w której powinniśmy pisać soft i w związku z tym to są jedyne słuszne rozwiązania.

Tymczasem, tak jak tutaj właśnie powiedziałeś, to jest jedynie pewne wprowadzenie rzeczy, które się gdzieś tam wcześniej sprawdziły, bo powiedzmy sobie szczerze, Gang of Four nie wymyślił tych wzorców projektowych, a przynajmniej nie wszystkie. To jest wynik lat doświadczeń programistów i zbierania różnych właśnie praktyk, które później można przekuć, tak jak w architekturze takiej tradycyjnej, w rozwiązania, które się zwyczajnie sprawdzają.

 

Tak, i też tutaj są różne rodzaje wzorców wzorce, które tu na poziomie, że tak powiem, takim operacyjnym używamy, ale są też wzorce takie architektoniczne, które są gdzieś tam level up, są wzorce, które mówią nam, jak np. moduły między sobą powinny się komunikować. Są  też takie wzorce z kolei specyficzne dla języków programowania, np. JavaScript ma swoje wzorce, języki obiektowe mają swoje, też języki funkcyjne, to pewnie Ty więcej nam opowiesz, ale nie sądzę, żeby to były te same wzorce.

 

Z pewnością nie. Zanim do tego przejdziemy, bo to jest właśnie ciekawe, jak różne paradygmaty w ogóle podchodzą do wzorców projektowych, to jeszcze tutaj pozostając w tych nadużyciach wynikających ze złego, niepoprawnego albo nadmiernego używania wzorców projektowych, nie można nie wspomnieć o code review jako miejscu, jako takim obszarze, gdzie wzorce projektowe często potrafią rozpalić do czerwoności i potrafią wzbudzić świętą wojnę. 

Bo właśnie tak jak powiedziałeś, ktoś zafascynowany jakimś wzorcem projektowym może próbować go na siłę forsować wszędzie, ponieważ wydaje się dla niego/dla niej, że to jest jedyne dobre rozwiązanie, a inna strona może albo po prostu uważać inaczej, albo nie znać zwyczajnie tego wzorca projektowego.

I tutaj pewnie nieraz nasi słuchacze mieli do czynienia właśnie z takimi uwagami od strony osób przeglądających, że może zastosowanie tego wzorca miałoby sens, że może tutaj spróbować to ugryźć za pomocą innego wzorca. 

I to ma takie swoje dwie strony. Z jednej strony jest to okazja do nauki, to też nie ma co tutaj tego nie doceniać, że możemy w praktyce zauważyć czy być poinformowanym, że można coś było zrobić prościej, przejrzyściej, czyściej, ale z drugiej strony, tak jak powiedziałeś, często forsujemy te wzorce projektowe tylko dlatego, żeby one tam były, a de facto nie wnosi to nic więcej. Są alternatywy, z których można skorzystać, więc tak, nie próbujmy tutaj na siłę na code review zarówno jako autorzy, jak i reviewerzy walczyć o wzorce projektowe, bo nie zawsze to ma sens.

 

To tu jeszcze mała anegdotka w takim razie o code review. Pamiętam kiedyś jeszcze na początku swojej kariery zrobiłem jakiś pull request, po czym kolega mówi: a Łukasz, wiesz, co tutaj za wzorzec projektowy użyłeś? A ja mówię: no ale ja tu żadnego wzorca nie użyłem. No ale tutaj jest tam taki wzorzec i taki, i wymyśliłem wzorzec, którego po prostu nie znałem, ale udało się zaimplementować i wymyślić.

 

Można i tak.

 

Okej, no to wracając, kiedy nie używać tych wzorców? Myślę, że też nie zawsze ma to sens, żeby ich używać od samego początku, jak coś robimy. Zawsze starajmy się robić jak najprostszy kawałek kodu w pierwszej kolejności, a dopiero później pewnie nastąpi refaktoryzacja do tego wzorcu, jeśli będzie taka potrzeba. Oczywiście nie zawsze. My informatycy wiemy, że takie kwantyfikatory silne jak: zawsze, nigdy, wszyscy, nikt, to nigdy w przyrodzie nie występują. Mam nadzieję, że zauważyliście, co tu zrobiłem.

Okej, no to wracając, kiedy nie używać tych wzorców? Myślę, że też nie zawsze ma to sens, żeby ich używać od samego początku, jak coś robimy. Zawsze starajmy się robić jak najprostszy kawałek kodu w pierwszej kolejności, a dopiero później pewnie nastąpi refaktoryzacja do tego wzorcu, jeśli będzie taka potrzeba. Oczywiście nie zawsze. My informatycy wiemy, że takie kwantyfikatory silne jak: zawsze, nigdy, wszyscy, nikt, to nigdy w przyrodzie nie występują. Mam nadzieję, że zauważyliście, co tu zrobiłem. 

 

To jest ciekawa rzecz, o której powiedziałeś, że nie zawsze na początku wiemy na tyle dużo na temat projektu, na temat też tych niefunkcjonalnych wymagań, że ciężko jest od razu powiedzieć, że dany wzorzec będzie tutaj pasował najlepiej. I możesz na tym się przejechać i to myślę, że z dwóch stron, bo może to być właśnie taki trochę over engineering, jeśli od razu próbujemy budować jakieś wielkie konstrukcje, bo wygląda albo być może się przydadzą w przyszłości, co tak jak tutaj właśnie powiedziałeś, nigdy prawie zawsze nie zachodzi. Natomiast z drugiej strony są, myślę, sobie takie podejścia, czy takie problemy, gdzie posiadając już określone doświadczenie, z dużą dozą prawdopodobieństwa można powiedzieć, że np. ta strategia, ta fasada, czy cokolwiek tam innego sobie weźmiemy, po prostu się sprawdzi.

Dodam jeszcze, że chyba łatwiej jest, jeśli myślimy o tych właśnie takich taktycznych, programistycznych, związanych z kodem wzorcach projektowych. Natomiast z architekturą, no różnie, są różne podejścia. Teraz coraz bardziej mówi się o tej architekturze takiej ewoluującej, gdzie no właśnie też nie betonujemy tych naszych rozwiązań, tylko raczej jesteśmy świadomi, że ta architektura będzie się zmieniała. Natomiast trudniej jest pewnie zastosować jakiś wzorzec architektoniczny z czasem, niż dokonać jakiejś optymalizacji, refaktoryzacji w kodzie i np. jakąś fabrykę nagle sobie wyciągnąć przed nawias.

 

Tak, a z drugiej strony też potrafię sobie wyobrazić, że np. w jednym projekcie już coś wymyśliliśmy, zrobiliśmy, nawet niekoniecznie to musi być wzorzec projektowy, ale jakiś schemat działania, który możemy nazwać wzorcem projektowym, coś działa fajnie, może możemy te doświadczenia po prostu przenieść na nowy projekt, który gdzieś tam robimy i od razu coś zrobić dobrze, jeśli wiemy, że te sytuacje gdzieś tam do siebie korespondują.

 

Tak, jeśli pasują, dokładnie. Dobrze, to może z drugiej strony powiedzmy, bo teraz powiedzieliśmy dosyć dużo na temat tego, jakie są jakieś antypaterny związane z tymi wzorcami projektowymi, kiedy niekoniecznie jest sens od razu z nimi startować, to może kiedy warto z nich korzystać.

Pewnie taki pierwszy punkt to jest po prostu nauka, która przychodzi z czasem i wówczas zauważamy, że albo coś często powielamy, albo coś występuje właśnie na tyle wiele razy, że warto jest to ubrać w jakiś wzorzec projektowy, i wtedy pewnie jako np. efekt refaktoryzacji, efekt właśnie nauki domeny możemy zastosować jakiś wzorzec projektowy.

Bo tutaj jeszcze o tym nie powiedzieliśmy, ale stosowanie tych uniwersalnych wzorców projektowych jest też swego rodzaju dokumentowaniem takim w przyszłość, bo zakładając, że większość deweloperów zna przynajmniej te podstawowe wzorce projektowe, to oznacza, że nowa osoba, która dołączy do projektu, będzie w stanie jakoś łatwiej, szybciej zrozumieć ten projekt.

 

Tak, to może powiedzmy, co to znaczy zna. Moim zdaniem wystarczyłoby, żeby wiedzieć po prostu, jakie problemy te wzorce rozwiązują. Pewnie nikt nie oczekuje, że zna to znaczy umie UML-a każdego wzorca z pamięci. To oczywiście można sobie wszystko sprawdzić, ale najważniejsze jest, żeby wiedzieć po prostu, jakie problemy da się rozwiązać danymi wzorcami. I to jest pewnie ta wiedza, która tutaj byłaby kluczowa.

Natomiast jeszcze inną może ciekawą rzecz tutaj powiem, jeśli chodzi o użycie wzorców. Spotkałem się z taką sytuacją, że cała biblioteka była oparta na jakimś wzorcu i jakby cały koncept polegał na tym, że biblioteka używa np. wzorca builder. Ostatnio używałem takiej fajnej biblioteczki, która pozwala z kodu C-sharpowego bezpośrednio wygenerować PDF bez widoków dodatkowych, tylko po prostu budujemy takiego tasiemca, załóżmy tam add page, kropka, add header, coś tam, coś tam, add paragraph, tak? I ładnie nam to generuje PDF-a. Dla takich prostych zastosowań całkiem fajne rozwiązanie. Nie trzeba tutaj się bawić w jakieś stylowanie, widoki.

 

Tak, wtedy jeśli wiesz, że to jest np. zbudowane na tym Builderze, to łatwiej jest Ci zrozumieć dokumentację, jak z tego korzystać, jeśli zajdzie taka potrzeba, to też wiesz, jak to rozszerzyć, więc to daje pewne możliwości, pewne ułatwienia, myślę sobie, jeśli taką wiedzę się posiada. Ale tak jak powiedziałeś, to nie chodzi o to, żebyśmy wiedzieli właśnie, jak pod spodem albo na jakich założeniach taki wzorzec jest zbudowany. Tak samo jak w architekturze budowlańcy nie potrzebują wiedzieć, jak wygląda rozkład sił w jakimś tam rozwiązaniu budowlanym. Wystarczy, że wiedzą, że do tego problemu pasuje właśnie ten wzorzec.

Tak, wtedy jeśli wiesz, że to jest np. zbudowane na tym Builderze, to łatwiej jest Ci zrozumieć dokumentację, jak z tego korzystać, jeśli zajdzie taka potrzeba, to też wiesz, jak to rozszerzyć, więc to daje pewne możliwości, pewne ułatwienia, myślę sobie, jeśli taką wiedzę się posiada. Ale tak jak powiedziałeś, to nie chodzi o to, żebyśmy wiedzieli właśnie, jak pod spodem albo na jakich założeniach taki wzorzec jest zbudowany. Tak samo jak w architekturze budowlańcy nie potrzebują wiedzieć, jak wygląda rozkład sił w jakimś tam rozwiązaniu budowlanym. Wystarczy, że wiedzą, że do tego problemu pasuje właśnie ten wzorzec.

 

Chyba że akurat idziemy na rozmowę o pracę. I to jest ten moment, gdzie te wzorce trzeba znać. Wiadomo, że zapytają tutaj.

 

Właśnie, to jest trochę śmieszne, to jest taki rekrutacyjny oczywiście antypatern, rodzaj teoretycznej wiedzy, którą próbuje się gdzieś tam badać, wyciągać od strony kandydatów, która później okazuje się, że jest kompletnie nieprzydatna w codziennej pracy.

 

Tak, tym bardziej że raczej to wygląda tak, że każdy swoją jakąś grupę po prostu ulubionych narzędzi, dwa, trzy, tak strzelam, które po prostu gdzieś tam się używa. Nie mówię tutaj nawet o takim złotym młotku, tak, ale po prostu gdzieś widzę lepiej miejsca, gdzie mogę tę strategię, zastosować niż tam, nie wiem, jakiś wzorzec, załóżmy chain of responsibility, który po prostu rzadko się używa.

W takiej koncepcji takiej rozmowy kwalifikacyjnej to pewnie to ma mały sens, a jeszcze jak się zapytają Cię: wybierz sobie tam dowolny i opisz ten, co wybrałeś, to pamiętaj, żeby nie wybierać Singletona, tylko żeby tutaj użyć właśnie jakiegoś wzorca, który ma renomę.

 

À propos tego już tutaj Singletona, okazuje się i to o tym tutaj też już wspomniałeś, że w tych nowoczesnych wydaniach języków programowania albo w nowoczesnych językach programowania wiele z tych rzeczy jest już albo jako core, albo nie ma potrzeby używania, nie ma potrzeby aplikowania tych wzorców tradycyjnych, ponieważ właśnie da się skorzystać z tych natywnych, wbudowanych elementów, które nam załatwiają tego typu problemy i pewnie to jest też droga rozwoju właśnie tych języków programowania, żeby łatać te rzeczy, żeby wypełniać te luki, które wzorce projektowe musiały na pewnym etapie gdzieś właśnie próbować niwelować.

 

Tak, choćby całe tutaj programowanie reaktywne, to wzorzec Observer, choćby tutaj już teraz moje przykłady, które miałem z rękawa do sypania, gdzieś wyparowały z głowy, ale teraz też w C Sharpie się pattern matching fajny pojawił, który też w dużej mierze np. Visitora potrafi zastąpić. I oczywiście całe IOC, które tutaj całe te wzorce kreacyjne, no nie całe, ale w dużej mierze obsługuje te sprawy kreacyjne i rzadko trzeba użyć czegoś z palca i napisać.

Może Builder jest takim właśnie fajnym przykładem, który fajnie też do testów jednostkowych się sprawdza, czy właśnie tak jak powiedziałem tutaj do takich biblioteczek, gdzie można po prostu użyć tego bardziej jako takiego wzorca, bym powiedział, nawet lekko architektonicznego, oczywiście w cudzysłowie.

 

Jasne. Wiesz, to byłoby ciekawe, żeby zobaczyć np. taki rozkład, jak często dane wzorce są wykorzystywane w różnych projektach. Myślę, że z pewnością są takie, z których korzysta się częściej, chociażby ten Builder, strategia, jakaś tam fasada, faktory, to pewnie gdzieś tam częściej wykorzystujemy, a są takie, gdzie to raczej jest taka ciekawostka teoretyczna niż coś, co często się widzi.

Ja ostatnio bardzo mocno siedzę w programowaniu funkcyjnym i to, co mnie zdziwiło, kiedy gdzieś tam się w tej domenie pojawiłem, to to, że tutaj praktycznie nie ma wzorców projektowych. Z czego to wynika? Wynika to m.in. z tego, że takim elementem budującym software w programowaniu funkcyjnym są funkcje. Po prostu wszystko da się ograć funkcjami i nie ma tutaj potrzeby, żeby coś więcej dodatkowo wprowadzać.

Oczywiście to nie znaczy, że my nie możemy sobie użyć podobnych trochę konceptów, jak w przypadku właśnie tych wzorców projektowych w OOP, chociażby przywołana tutaj fasada czy jakaś strategia, pewnie dałoby się to jakoś tam wykorzystać, ale trafiłem jakiś czas temu na taki artykuł, który próbował właśnie te najczęściej stosowane wzorce projektowe w Elixirze konkretnie zaimplementować i to wszystko wyglądało strasznie pokracznie, w sensie nikt tego typu rzeczy nie robiłby właśnie w rzeczywistym projekcie, bo da się to ograć, da się to zrobić za pomocą tych natywnych rozwiązań, które są.

Kolejny dowód, kolejny przykład na to, że nie zawsze powinniśmy próbować aplikować te wzorce projektowe wszędzie, gdzie się tylko da, bo są po prostu lepsze natywne rozwiązania, alternatywy albo wręcz nie ma potrzeby wykorzystywania wzorców projektowych. Tak też może być.

 

Tak, zgadzam się tutaj z Tobą. Oczywiście w dużej mierze to też zależy od języka programowania, paradygmatu programowania. Wzorce nie są czymś, co jest w 100% uniwersalne, ale na pewno nie zaszkodzi wiedzieć po prostu, jakie problemy da się nimi rozwiązać.

I co? Myślę, że tutaj powoli będziemy zmierzać do konkluzji naszego spotkania.

 

Tak, dokładnie. Ja może pokuszę się o pierwszy punkt. Taką naszą niepisaną tradycją jest to, że to Łukasz robi podsumowania, ale może spróbujemy dzisiaj wspólnymi siłami do tego podejść.

Z mojej perspektywy wzorce projektowe mogą być cennym rozwiązaniem, ale trzeba podejść w taki sposób odpowiedzialny do ich wykorzystania i nie próbować wszędzie wykorzystywać właśnie tych świeżo poznanych wzorców projektowych. Często okazuje się, że to jest over engineering często okazuje się, że w wyniku refaktoryzacji ten kod i tak się zmieni, ponieważ to, co nam się wydawało na początku, że będzie idealnym rozwiązaniem, wcale takim nie jest.

 

Kolejnym punktem podsumowania będzie też fakt, że zanim użyjecie jakiegoś wzorca, to też sprawdźcie, czy Wasz język programowania albo biblioteki, które są tam standardowe w danym ekosystemie, nie rozwiązują po prostu danych problemów czy też wprost nie implementują np. tych wzorców programowania. Nie zawsze trzeba pisać coś od zera z palca, czasami już są gotowe elementy. Wiadomo, że używając czegoś, co już jest, to raczej mniejsza szansa na popełnienie błędów.

I pewnie ostatni punkt, pamiętajcie, że nie musicie tutaj kuć na blachę tych wszystkich wzorców, wystarczy taka ogólna wiedza o tym, jakie problemy one rozwiązują.

 

Tak, warto idąc na rozmowę rekrutacyjną, przynajmniej na te początkowe stanowiska, jakoś ogólnie sobie przypomnieć te wzorce projektowe, przynajmniej te najistotniejsze, ale kiedy już dostaniecie tę pracę, to nie próbujcie na code review za wszelką cenę ich forsować.

 

I uwaga jeszcze na koniec: pamiętajcie, że każdy wzorzec ma swoje silne strony, słabe strony. Czasami może być uznany za antypatern, czasami mimo, że jest uznawany za antypatern, to w tej danej sytuacji jednak ma to sens. I postarajcie się po prostu znać te słabe i silne strony tych wzorców. Nie polegajcie na tym, że ogólnie wszyscy mówią, że ten Singleton jest zły, to jego nie wolno używać. Może akurat w Waszej sytuacji gdzieś tam jest, czy ten template method jest ta sytuacja, gdzie napisanie tego w inny sposób byłoby nieefektywne kosztowo. Trzeba zawsze mierzyć siły na zamiary i tutaj odpowiednio dobrać narzędzia do swojego problemu. 

 

Dokładnie. Wzorcowe podsumowanie teraz będziemy wzorcowo kończyć. Dzięki, Łukasz, za rozmowę. 

 

Dzięki, Krzysztofie. 

Jak zawsze zapraszamy także na SolidJobs. Jeśli szukacie pracy lub szukacie rąk do pracy, jest to idealne miejsce. Zapraszamy. 

 

Dokładnie. Zapraszamy do wcześniejszych odcinków, do następnych w ramach tej serii. Do usłyszenia następnym razem.

Cześć! 

 

Do usłyszenia. Dzięki, cześć!