Wzory strukturalne

2.1 Adapter

Adapter (Adapter) to strukturalny wzorzec projektowy przeznaczony do organizowania korzystania z funkcji obiektu, który nie jest dostępny do modyfikacji za pośrednictwem specjalnie utworzonego interfejsu.

Oficjalna definicja jest nieco skomplikowana, ale jeśli ubierzesz ją własnymi słowami, adapter to wzorzec projektowy, który umożliwia współpracę obiektów z niekompatybilnymi interfejsami .

Służy do organizowania korzystania z funkcji obiektu, który nie jest dostępny do modyfikacji za pomocą specjalnie utworzonego interfejsu. Tworzona jest dodatkowa klasa, która ma wymagany interfejs, a ta z kolei wywołuje metody żądanego obiektu (który nie ma wymaganego interfejsu).

Ważny! Jeśli w kodzie spotkasz sufiks Adapter dla klasy, to masz pełne prawo uznać, że ta klasa działa jako adapter i jest powiązana z grupą klas, które działają zgodnie ze schematem opisanym powyżej.

Jest używany w przypadkach, gdy system obsługuje wymagane dane i zachowanie, ale ma nieodpowiedni interfejs. Najczęstszym zastosowaniem wzorca Adapter jest tworzenie klasy dziedziczącej po nowej lub istniejącej klasie abstrakcyjnej.

Silne strony:

• Przejście na korzystanie z innych zewnętrznych klas nie wymaga przerabiania samego systemu, wystarczy zaimplementować jeszcze jedną klasę Adapter.
• Niezależność od implementacji klas zewnętrznych (klas z bibliotek, których kodu nie możemy zmienić). Twój program uniezależnia się od interfejsu klas zewnętrznych.

2.2 Dekoratorzy

Dekorator to strukturalny wzorzec projektowy służący do dynamicznego dołączania dodatkowych zachowań do obiektu. Wzorzec Decorator zapewnia dobrą i elastyczną alternatywę dla praktyki dzielenia na podklasy w celu rozszerzenia funkcjonalności.

Służy do dynamicznego łączenia dodatkowych zobowiązań z obiektem.

Wielu z was zapyta: w jaki sposób można dynamicznie (podczas działania programu) dodawać nowe zachowanie do obiektu? Obiekt można złożyć z kawałków, czyli małych przedmiotów. Pamiętasz łańcuchy filtrów w serwletach? A może Stream API podczas pisania zapytania przy użyciu filter(), map(), list()?

IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);

Mocne strony wzorca Dekorator:

• Nie ma potrzeby tworzenia podklas, aby rozszerzyć funkcjonalność obiektu.
• Możliwość dynamicznego łączenia nowej funkcjonalności w dowolnym miejscu: przed lub po głównej funkcjonalności obiektu ConcreteComponent.

2.3 Pełnomocnicy

Proxy to strukturalny wzorzec projektowy, który zapewnia obiekt kontrolujący dostęp do innego obiektu, przechwytując i przepuszczając wszystkie jego wywołania.

Wzorzec Proxy zapewnia zastępczy obiekt zamiast rzeczywistego obiektu. Ten obiekt kontroluje dostęp do oryginalnego obiektu. Używany bardzo często.

Pamiętasz, jak wykorzystaliśmy framework Mockito i przechwyciliśmy wywołanie rzeczywistego obiektu za pomocą metody Mockito.spy() lub adnotacji @Spy? Właśnie wtedy powstał specjalny obiekt Proxy, przez który przechodziły wszystkie wywołania do pierwotnego obiektu.

Następnie moglibyśmy zarządzać tymi wywołaniami, dodając reguły do ​​obiektu. Zgadza się – oryginalny obiekt się nie zmienia, a praca z nim staje się znacznie bardziej elastyczna. Jest to szczególnie przydatne, gdy nie wywołujemy obiektu proxy z naszego kodu, ale gdzieś go przekazujemy. Kontrolując w ten sposób komunikację dwóch niezależnych od nas obiektów.

Rodzaje pełnomocników według celu:

• Logowanie proxy : rejestruje wszystkie połączenia z „Tematem” wraz z ich parametrami.
• Zdalne proxy (remote proxy): zapewnia komunikację z „Podmiotem”, który znajduje się w innej przestrzeni adresowej lub na zdalnej maszynie. Może być również odpowiedzialny za zakodowanie żądania i jego argumentów oraz wysłanie zakodowanego żądania do prawdziwego „Podmiotu”.
• Wirtualne proxy (wirtualne proxy): zapewnia, że ​​prawdziwy „Podmiot” jest tworzony tylko wtedy, gdy jest naprawdę potrzebny. Może również przechowywać w pamięci podręcznej niektóre informacje o prawdziwym „podmiocie”, aby opóźnić jego utworzenie.
• Kopiowanie przy zapisie : Udostępnia kopię „podmiotu”, gdy klient wykonuje określone działania (specjalny przypadek „wirtualnego proxy”).
• Serwery proxy ochrony : mogą sprawdzić, czy dzwoniący ma uprawnienia niezbędne do wysłania żądania.
• Caching Proxy : Zapewnia tymczasowe przechowywanie wyników obliczeń przed udostępnieniem ich wielu klientom, którzy mogą udostępniać wyniki.
• Pełnomocnik przesiewowy: chroni „Podmiot” przed niebezpiecznymi klientami (lub odwrotnie).
• Serwer proxy synchronizacji : przeprowadza zsynchronizowaną kontrolę dostępu do „Podmiotu” w asynchronicznym środowisku wielowątkowym.
• „Inteligentne” łącze (inteligentne proxy referencyjne): wykonuje dodatkowe czynności po utworzeniu łącza do „Tematu”, na przykład oblicza liczbę aktywnych łączy do „Tematu”.

2.4 Most

Wzorzec Bridge to strukturalny wzorzec projektowy używany do „oddzielenia abstrakcji i implementacji, aby mogły się zmieniać niezależnie”.

Wzorzec mostka wykorzystuje enkapsulację, agregację i może wykorzystywać dziedziczenie do podziału odpowiedzialności między klasami.

Kiedy abstrakcja i implementacja są rozdzielone, mogą zmieniać się niezależnie. Innymi słowy, po zaimplementowaniu poprzez wzorzec pomostowy zmiana struktury interfejsu nie koliduje ze zmianą struktury implementacji.

Rozważ taką abstrakcję jako figurę. Istnieje wiele rodzajów kształtów, z których każdy ma swoje własne właściwości i metody. Jest jednak coś, co łączy wszystkie postacie. Na przykład każdy kształt musi mieć możliwość rysowania, skalowania i tak dalej.

Jednocześnie rysowanie grafiki może się różnić w zależności od typu systemu operacyjnego lub biblioteki graficznej. Kształty powinny mieć możliwość rysowania się w różnych środowiskach graficznych. Jednak implementowanie wszystkich metod rysowania w każdym kształcie lub modyfikowanie kształtu za każdym razem, gdy zmienia się metoda rysowania, jest niepraktyczne.

W tym przypadku pomocny jest wzorzec bridge, pozwalający na tworzenie nowych klas, które zaimplementują rysowanie w różnych środowiskach graficznych. Korzystając z tego podejścia, bardzo łatwo jest dodawać zarówno nowe kształty, jak i sposoby ich rysowania.

Związek reprezentowany przez strzałkę na diagramach może mieć 2 znaczenia: a) „rodzaj”, zgodnie z zasadą podstawienia Liskowa, oraz b) jedna z możliwych implementacji abstrakcji. Języki zwykle używają dziedziczenia do implementacji zarówno a), jak i b), co ma tendencję do rozdęcia hierarchii klas.

Most służy właśnie do rozwiązania tego problemu: obiekty tworzone są parami z obiektu klasy hierarchii A i hierarchii B, dziedziczenie w hierarchii A ma według Liskowa znaczenie „różnorodności”, a dla koncepcji „implementacji abstrakcji” używane jest łącze z obiektu A do jego sparowanego obiektu B.

2.5 Fasada

Wzorzec fasady to strukturalny wzorzec projektowy, który ukrywa złożoność systemu, redukując wszystkie możliwe wywołania zewnętrzne do jednego obiektu, który deleguje je do odpowiednich obiektów w systemie.

Jak zapewnić ujednolicony interfejs z zestawem odmiennych implementacji lub interfejsów, na przykład do podsystemu, jeśli silne powiązanie z tym podsystemem jest niepożądane lub implementacja podsystemu może ulec zmianie?

Zdefiniuj jeden punkt interakcji z podsystemem – obiekt fasady, który zapewnia wspólny interfejs z podsystemem i przypisz mu odpowiedzialność za interakcję z jego komponentami. Fasada jest obiektem zewnętrznym, który zapewnia pojedynczy punkt wejścia dla usług podsystemu.

Implementacja pozostałych komponentów podsystemu jest prywatna i niewidoczna dla komponentów zewnętrznych. Obiekt Fasada zapewnia implementację wzorca GRASP Odporny na zmiany w zakresie ochrony przed zmianami w implementacji podsystemu.

Ważny! Wzorzec ten stosujemy, gdy chcemy całkowicie ukryć jakąś grupę obiektów i całą komunikację z nimi przekazać przez nasz obiekt. Jeśli chcesz tylko zapewnić pewną kontrolę nad procesem komunikacji obiektów i niekoniecznie je ukrywać, lepiej jest użyć wzorca Proxy.