Celem zastosowania wzorca Obserwator w tworzeniu aplikacji WEB jest:
Wzorzec projektowy Obserwator (ang. Observer) to jeden z klasyków ze świata programowania obiektowego i frontendu. Główna jego rola polega na tym, by pozwalać obiektom (obserwatorom) reagować na zmiany stanu innych obiektów (podmiotów) bez sztywnego powiązania tych klas ze sobą. W praktyce, w aplikacjach webowych bardzo często wykorzystuje się ten wzorzec w architekturach typu MVC czy MVVM, gdzie widoki muszą się automatycznie aktualizować po zmianie modelu danych. Przykład: w Reactcie używasz hooka useState lub useEffect – i Twoje komponenty „obserwują” stan aplikacji. Gdy stan się zmienia, komponenty same się przebudowują, a Ty nie musisz ręcznie wywoływać każdej aktualizacji. Podobnie działa np. EventEmitter w Node.js, Redux z subskrypcjami store czy nawet WebSockety, gdzie klient „słucha” na zmiany po stronie serwera. Dzięki temu komunikacja pomiędzy różnymi częściami systemu staje się luźno powiązana, co ułatwia utrzymanie i rozbudowę kodu. Moim zdaniem bez zrozumienia tego wzorca trudno ogarnąć nowoczesny frontend, bo większość bibliotek UI gdzieś pod spodem go wykorzystuje. Przy okazji: Observer to wzorzec zalecany przez GOF (Gang of Four), więc to nie jest tylko „fajna technika”, ale sprawdzony standard branżowy. Warto wiedzieć, że podejście to minimalizuje ryzyko błędów w synchronizacji danych i pozwala naturalnie reagować na zmiany bez pisania stosów callbacków. To spora oszczędność czasu i kodu.
Często można się pomylić, próbując „wymyślić” jakąś funkcjonalność, którą może realizować wzorzec Obserwator w aplikacji webowej. Jednak nie każda aktywność związana ze zmianami w systemie czy komunikacją między komponentami to domena właśnie tego wzorca. Z mojego doświadczenia, widzę że wiele osób myli obserwatora z mechanizmami monitorującymi zachowanie użytkownika, jak narzędzia do śledzenia kliknięć czy generowania wyjątków w reakcji na nietypowe akcje – tymczasem Obserwator nie służy do analityki lub obsługi logiki wyjątków. To raczej narzędzie do powiadamiania powiązanych obiektów o zmianach, które zachodzą w jednym z nich. Spotkałem się także z opinią, że wzorzec ten zarządza funkcjami synchronicznymi. W praktyce nie ma on nic wspólnego z zarządzaniem synchronicznością czy asynchronicznością kodu – sam jest neutralny względem tych aspektów. Synchroniczność lub asynchroniczność zależy raczej od implementacji (np. Promises, async/await, event loop), a nie od samego wzorca Obserwator. Jeszcze inny częsty błąd to utożsamianie tego wzorca z mechanizmami dostosowującymi interfejs użytkownika do różnych profili użytkowników. To już bardziej domena wzorców strategii, kompozycji lub nawet prostych warunków w kodzie. W skrócie: Obserwator to taki „kurier”, który informuje zainteresowanych, gdy coś się zmienia – i tylko tyle. Jak dla mnie, zrozumienie tej granicy pomaga uniknąć niepotrzebnych komplikacji w projektowaniu architektury aplikacji webowych.