Ponad 4.5 roku temu rozpocząłem serię artykułów na blogu o wzorcach projektowych. Następnie przez 3 kolejne lata opracowałem i opisałem je wszystkie (te zebrane w pierwszej publikacji ponad 30 lat temu). W kolejnym roku zrealizowałem kilka warsztatów, w których uczyłem innych programistów praktycznego zastosowania wzorców. To doprowadziło mnie do kilku wniosków…
Wzorce projektowe to po prostu rzetelne programowanie obiektowe. Zakładam, iż przez cały czas większość z Was porusza się w tym paradygmacie i nadrzędnym celem powinno być jego zrozumienie. Pamiętam, jak na początku przygody opakowywałem strukturalny kod w klasy i obiekty. Niby wiedziałem, jakie są cztery filary programowania obiektowego: dziedziczenie, abstrakcja, hermetyzacja i polimorfizm, a jednak nie do końca stosowałem je w praktyce. Wydawało mi się, iż programuję obiektowo, ale to właśnie zrozumienie wzorców projektowych pokazało mi, iż się myliłem. To jedna z dwóch głównych dróg. Ta druga zakłada, iż najpierw zrozumiecie programowanie obiektowe, a następnie podczas nauki wzorców projektowych okaże się, iż wielu z nich nieświadomie używaliście już wcześniej. W praktyce najczęściej obie te ścieżki przeplatają się ze sobą i wzajemnie się uzupełniają.
Nie ma wątpliwości, iż programista posługujący się daną technologią i danym paradygmatem powinien płynnie poruszać się w tym środowisku. To z kolei prowadzi do wniosku, iż wzorce projektowe są niezbędne. Ale czy musicie znać i stosować wszystkie? Nie. Istnieją wzorce, których używa się regularnie w wielu projektach, bo rozwiązują dość często występujące problemy. Są natomiast takie, których możliwe, iż nie użyjecie produkcyjnie przez całą karierę i to nie dlatego, iż ich nie znacie. Po prostu pasują do bardzo specyficznego problemu. Poza tym mnogość wzorców może Was przytłoczyć. Szczególnie, iż część z nich wygląda podobnie, a odróżnia je wyłącznie intencja użycia.
Podczas warsztatów wybierałem tylko kilka wzorców projektowych i dogłębnie je analizowaliśmy. Wyłącznie te, które z powodzeniem można użyć już w pierwszych tygodniach od ich poznania np. Adapter czy Strategia. Rozwiązują często powtarzające się problemy, a ryzyko przeinżynierowania jest niewielkie. Dość łatwo wycofać się z ich niewłaściwego użycia. Naturalnie, im pojemniejsza skrzynka narzędziowa, tym lepsze dopasowanie rozwiązania do problemu. Docelowo warto kojarzyć wszystkie wzorce projektowe i chociaż znać ich ogólne przeznaczenie. Po dokładną implementację zawsze można spojrzeć do ściągawki.
No właśnie, ściągawki… Nauka wzorców projektowych może powodować dezorientację, bo jakość materiałów bywa różna. Też nie jestem bez winy. Z perspektywy czasu, gdy patrzę na przykłady z mojego bloga, muszę przyznać, iż nie wszystkie są idealne. Dwa główne problemy z istniejącymi w sieci materiałami o wzorcach projektowych, które dostrzegam to: odrealnione przykłady i przykłady wyciągnięte z kontekstu.
Ten pierwszy skutecznie udało mi się rozwiązać swoimi treściami na blogu. Z tym drugim poradziłem sobie dopiero przy realizacji warsztatów. Artykuły o wzorcach projektowych zawsze traktowałem jak pewną bazę wzorców do której można wrócić i przypomnieć sobie kiedy, po co i jak. Narysowanie szerszego kontekstu byłoby trudne i zaciemniałoby samą granicę, gdzie zaczyna i kończy się impementacja wzorca. Mimo wszystko, wiem iż często największym wyzwaniem jest użycie wzorca w kodzie. Przełożenie struktury klas z przykładu na własne poletko jest banalne. Trudniejsza kwestia to wpięcie wzorca w cały proces od żądania do odpowiedzi. Nieraz, w ramach rozwiązania problemu trzeba posklejać kilka wzorców, a to są kwestie, które wynikają bardziej z praktyki, niż teorii.
Brak praktyki to kolejny istniejący problem. Tylko teoretyczna znajomość wzorców projektowych. Obawa przed błędnym użyciem albo nauka tylko pod rekrutację. Zamiast przerabiać kolejne materiały o wzorcach projektowych zacznijcie ich używać w projektach. Tak wiem: stara aplikacja, brak złożonych do rozwiązania problemów, framework narzuca architekturę i inne wymówki. Oczywiście nie jestem orędownikiem nadmiarowego stosowania wzorców projektowych wszędzie. Gwarantuję Wam jednak, iż istnieje szerokie pole do używania tych narzędzi w prawie każdym projekcie i nie pozwólcie żeby leżały one zardzewiałe w Waszych skrzynkach.
Jeżeli dobrze programujecie obiektowo to używacie wzorców projektowych.
Zgodzę się, iż nie zawsze trzeba się zastanawiać, czy jeszcze jest to Adapter, czy może już bardziej Fasada. To wyłącznie kwestia komunikacyjna. Ważniejsze okaże się, jakie rozwiązanie dobieracie do jakiego problemu i dlaczego to robicie. Wzorce projektowe opierają się o cztery podstawowe filary programowania obiektowego, a w dodatku są zgodne z dobrymi praktykami jak SOLID.
Warto stosowować obiektowe wzorce projektowe!
Wpis Wzorce projektowe programowania obiektowego – czy warto się ich uczyć i dlaczego tak. pojawił się pierwszy raz pod Koddlo.
