Adam's Coding Corner

Zadaniem Mediatora jest organizować komunikację między bliskimi klasami. Wzorzec `Mediator` uwalnia zależności pomiędzy komponentami. Przejmuje na siebie interakcję między nimi, stając się głównym hubem komunikacyjnym dla grupy klas. Odwracamy sterowanie, ponieważ komponenty zaczynają informować tylko 'co się stało', zamiast nakazywać innym, żeby 'coś zrobiły'. Można go spotkać np. pod postacią `ViewModel` w Androidzie, gdzie oddziela interakcje UI od zmian modelu danych.

`Dekorator` stosuje się tam, gdzie tworzenie osobnych klas będących kombinacją wszystkich możliwości skończyłoby się ich eksplozją. Wzorzec ten skupia się na stworzeniu warstw obiektów w celu transparentnego i dynamicznego uzupełniania obiektów o kolejne zadania. Dekorator dostarcza obiekt, o takim samym interfejsie co obiekt dekorowany.

Adapter lub Wrapper pozwala `przetłumaczyć` jeden interfejs na inny, oczekiwany przez klienta. Jest to szczególnie przydatne, gdy adaptowany obiekt pochodzi z niezależnej biblioteki i nie chcemy uzależniać naszego systemu od jego interfejsu, tworząc tzw. `anticorruption layer`. Zmiany interfejsu obiektu wpłyną tylko na `Adapter` a nie na resztę kodu.

IntelliJ IDEA całkiem sprawnie radzi sobie z obsługą LaTeX. Śmiem twierdzić, że jest to nawet lepsze doświadczenie niż TexStudio czy Texmaker, które są dedykowane do tego typu projektów. Jednak siła IntelliJ nie polega na możliwościach `out of the box` ale na plugin-ach i ręcznej konfiguracji procesu budowania.

Fasada pozwala a ukrycie szczegółów modułu przed klientami. Zapewnia przestrzeganie `Prawa Demeter`, a użycie ogólnego interfejsu i różnych implementacji znacząco ułatwia testowanie. Dobrze łączy się z innymi wzorcami takimi jak `Strategia`, `Metoda Szablonowa` czy konstrukcyjnymi pozwalającymi na konfigurację obiektu udostępnianego klientom. Fasada dobrze nadaje się na punkt wejścia dla bibliotek, dając klientom dostęp do wysokopoziomowych funkcjonalności i chowając całą wewnętrzną logikę i klasy.

Strategia tworzy rodzinę algorytmów, zamykając różniącą się logikę w osobnych klasach, jednocześnie ukrywając ją przed klientami za wspólnym interfejsem. Umożliwia wymienne stosowanie implementacji. Użycie strategii znacząco upraszcza kod klientów, pozwala uniknąć duplikacji kodu i instrukcji warunkowych. Znacząco ułatwia testowanie — oddzielając testowanie klienta od algorytmów strategii.

Metoda szablonowa to bardzo prosty wzorzec, pozwalający oddzielić to, co stałe od tego, co zmienne w rodzinie klas. Polega na utworzeniu abstrakcyjnej klasy nadrzędnej, zawierającej kolejne kroki jakiegoś algorytmu i pozwoleniu klasom dziedziczącym z niej nadpisywać poszczególne kroki, ale nie sam algorytm, który je wykorzystuje.

Fabryka fabryk, czyli 'Abstract Factory' usprawnia tworzenie obiektów będących częścią jakiejś 'rodziny'. Jest to w zasadzie warstwa opakowująca konkretne fabryki i dostarczająca klientom instancję fabryki tworzącą obiekty z danego wariantu.

Po `Static Factory Method` nadeszła pora na klasyczne `Factory`. Fabryka jest bardzo użytecznym i często stosowanym wzorcem konstrukcyjnym. Kotlin daje nam ciekawe możliwości dzięki klasom `sealed` oraz `internal`, których odpowiedników brakuje w Javie.

Znane z Javy `Statyczne Metody Wytwórcze` w Kotlinie jak najbardziej mają swoje zastosowanie, pomimo trochę innego zachowania i braku słówka `static`. Postaram się przybliżyć czym jest `companion object` i jak go można używać. PS: Ten post miał byc o wzorcu Factory Method z tylko krótką wzmianą o statycznych metodach fabrycznych, ale ten temat okazał się ciekawszy, niż sądziłem :)