Wzorce projektowe w systemach e-commerce

Rafał Baran | Rozwój oprogramowania | 15.07.2020

Systemy e-commerce charakteryzują się dużą złożonością. Dzięki niej jednak programiści zyskują bardzo dużą elastyczność w projektowaniu. Aby system był czytelny dla programisty, każda aplikacja e-commerce powinna powstawać w oparciu o ogólnie przyjęte wzorce projektowe. W dzisiejszym tekście chciałbym przybliżyć dobre praktyki i opisać wybrane wzorce, ale i przestrzec przed antywzorcami, które też niestety czasami się pojawiają.

E-commerce – od czego zacząć?

Próg wejścia w przypadku programowania systemów e-commerce, ze względu na ich złożoność, jest dużo większy niż w przypadku pisania systemu od podstaw. Żeby zacząć rozwijać taką aplikację, potrzebne są więc spora wiedza i doświadczenie. Tworząc taki system, można dużą część funkcjonalności pokryć funkcjami “out of the box”, jakich nam dostarcza jego wersja domyślna. Natomiast modyfikacje takiego systemu wymagają już sporej wiedzy na temat jego budowy i funkcjonowania.

Pracę nad aplikacją e-commerce dobrze jest zacząć od szkolenia z zakresu programowania w danej technologii. W ten sposób zdobywamy podstawową wiedzę na temat dobrych praktyk programowania w projekcie. Często zdarza się, że systemy e-commerce wykorzystują gotowe frameworki służące do pisania aplikacji. Złożoność takich systemów jest duża, jednak owocuje to korzyściami dla programistów i użytkowników. Otrzymujemy potężne aplikacje, które są bardzo elastyczne oraz mają spore możliwości konfiguracyjne dla użytkownika obsługującego je od zaplecza.

Czytaj także: Frameworkowe wojny

Nikt nie obiecywał, że będzie łatwo…

Poruszanie się w gąszczu wzorców nie należy do najłatwiejszych. Ponadto jedna funkcjonalność może wpływać na drugą i trzeba wcześniej upewniać się co do wdrażanych modyfikacji w systemie. Warto też pamiętać, że wszystkie modyfikacje należy wykonywać zgodnie z zasadami. Dlatego właśnie moim zdaniem utrzymywanie systemów e-commerce jest trudniejsze niż ich pisanie.

Duże systemy e-commerce napisane w technologii PHP, takie jak Magento czy Shopware, korzystają z bibliotek Symfony i Zend. Na rynku mamy wiele podobnych rozwiązań gotowych do instalacji i rozbudowy. Niektóre systemy oferują wprawdzie wersję enterprise dla bardziej wymagających klientów, jednak licencja jest zazwyczaj kosztowna i przeznaczona dla dużych systemów. Warto więc rozważyć kastomizację, która będzie tańsza i będzie w pełni spełniać wymagania naszej firmy. Co ważne, na rynku narzędzi e-commerce zaczęły się już pojawiać systemy, które można łatwo skalować w chmurze AWS, Google Cloud lub Azure. Idealnie więc jest mieć rozwiązanie, które pozwala na migrację pomiędzy chmurami. Aby stworzyć tak skomplikowany system, trzeba trzymać się sztywnych reguł pisania aplikacji. Jak więc ułatwić sobie pracę? [promotions id=49]

Najważniejsze wzorce projektowe w e-commerce

Wzorców projektowych w pisaniu systemów informatycznych jest mnóstwo i nie chciałbym się skupiać na wymienianiu wszystkich. Postaram się przybliżyć najważniejsze z nich, które przynoszą największe korzyści pod względem jakości kodu. Oto kilka wzorców projektowych, bez których stworzenie jakiejkolwiek aplikacji komercyjnej byłoby wręcz niemożliwe.

Wyróżniamy trzy rodzaje wzorców projektowych:

Kreacyjne

Opisują one procesy tworzenia nowych obiektów, do ich zadań należą także wszelkie czynności związane z ich konfiguracją oraz tworzeniem typów danych.

  • Property – to najbardziej podstawowy z wzorców kreacyjnych. Służy głównie do przetrzymywania konfiguracji, jest to bardzo ważne ze względu na to, że eliminuje ryzyko duplikowania wartości konfigurujących oraz ułatwia późniejsze modyfikacje i utrzymywanie kodu.
  • Abstract factory – jest wzorcem, który może posłużyć w budowaniu aplikacji, określa on interfejs do tworzenia różnych obiektów należących do tego samego typu (domeny).
  • Factory method – jest podobnym wzorcem do abstract factory. Również określa interfejs, z tym, że odnosi się do różnych metod zamiast obiektów.

    Strukturalne

    Definiują struktury powiązanych ze sobą obiektów.
  • Adapter – to przykład wzorca strukturalnego, który może posłużyć obsługi niezgodnych interfejsów w obiektach. Jego zadaniem w takim przypadku jest umożliwienie komunikacji takich obiektów.
  • Facade – to kolejny wzorzec strukturalny. Przechowuje on mapę obiektów wraz z możliwością ich obsłużenia. Implementacja tego wzorca może odbyć się przez stworzenie klasy oraz osadzenie w niej wszystkich obiektów, które realizują konkretną logikę aplikacji.

    Czynnościowe

    Opisują wzajemne zależności pomiędzy obiektami.

  • Observer – to jeden z popularnych wzorców czynnościowych. Służy on do obsługi zdarzeń w aplikacjach i dzięki niemu aplikację można łatwo rozszerzać. Przykładem takiego zdarzenia w systemie e-commerce może być moment wystawienia faktury za transakcję. Przykładowo, programista w zależności od wymogów biznesu może zaprogramować jakąś akcję po wystawieniu faktury, np. dodatkowe powiadomienie dla pracownika sklepu.
  • Dependency injection – kolejnym wzorcem czynnościowym jest dependency injection. Polega on na „wstrzykiwaniu” zależności jednego obiektu do drugiego oraz wykonywanie na nim operacji, na podstawie których jest realizowana logika aplikacji. Pozwala na usuwanie zależności pomiędzy danymi komponentami.

Pomyślę o tym później – czyli antywzorce projektowe

Pisząc o wzorcach w e-commerce, chciałbym wspomnieć także o antywzorcach projektowych, których również jest sporo.

  • Gold platingciekawym antywzorcem projektowym jest gold plating, czyli tzw. złocenie. Mamy z nim do czynienie w sytuacji, gdy prace nad projektem lub zadaniem trwają dłużej, niż jest to wymagane (np. z powodu ciągłego ulepszania funkcjonalności i chęci dostarczenia klientowi jeszcze lepszego produktu). W pewnym momencie zostaje jednak przekroczony punkt krytyczny, w którym dodatkowy wysiłek nie przynosi wartości dodanej w projekcie.
  • We’ll handle it laterprzykładem równie skrajnym jest wspomniane we’ll handle it later, czyli tzw. „Na tym etapie bym się tym nie przejmował”. Antywzorzec ten stosowany jest, gdy analiza danego zadania lub projektu nie została wykonana prawidłowo lub nie została przeprowadzona w ogóle.
  • U mnie działa – kto z nas nie słyszał choć raz w życiu „U mnie działa?”. To często spotykane stwierdzenie można często spotkać przy uruchomieniu aplikacji na różnych systemach operacyjnych lub przy w różnych środowiskach klienckich. A przecież warto zbadać każde zgłoszenie – ignorowanie problemów na początkowym etapie może mieć dalsze konsekwencje na późniejszych etapach projektów.
  • Hard code – tzw. umieszczenie w kodzie tej samej zmiennej w kilku miejscach, co drastycznie wpływa na późniejsze utrzymanie takiej aplikacji.

Podsumowanie

Systemy e-commerce nie tracą na popularności i dają duże możliwości zarówno użytkownikom, jak i programistom. Aby nie pogubić się w ich złożoności i w pełni wykorzystać ich potencjał, warto wystrzegać się opisanych przeze mnie antywzorców i pogłębiać swoją wiedzę na temat dobrych praktyk. Nie tylko w programowaniu przekładają się one na najlepsze rezultaty. Mam nadzieję, że opisane przeze mnie przykładowe wzorce zachęcą Was do poznania kolejnych i stosowania ich w projektach. [promotions id=32]