Wzorce projektowe

1.1 Wprowadzenie do wzorców

Jak wspomniano wcześniej, programista rozpoczyna pracę nad programem od zaprojektowania jego modelu: sporządzenia listy podmiotów, na których program będzie działał. Im więcej podmiotów w programie, tym bardziej złożony program.

Dlatego, aby zmniejszyć złożoność programu, starają się ustandaryzować interakcje obiektów. I tutaj wzorce projektowe lub wzorce projektowe bardzo pomagają programiście . Z angielskiego wzorca projektowego .

Ważny! W języku rosyjskim słowo projekt zwykle oznacza projekt graficzny, w języku angielskim tak nie jest. Angielskie słowo design jest bliższe znaczeniu słowu „projekt” i/lub „urządzenie”. Na przykład projekt silnika to nie jego wygląd, ale jego wewnętrzna struktura.

Dlatego wzorzec projektowy jest dokładnie wzorcem/wzorem projektowym. Zalecam całkowite zaprzestanie używania słowa projekt w znaczeniu „wygląd”. Jesteś przyszłym Inżynierem Oprogramowania, a dla Ciebie projektowanie jest właśnie projektowaniem.

Czym więc jest ten wzorzec projektowy? Przede wszystkim wzorzec projektowy to standardowe rozwiązanie standardowego problemu . Dobre, skuteczne i sprawdzone rozwiązanie.

Powiedzmy, że zostałeś poproszony o zaprojektowanie roweru, możesz zrobić z niego dwa koła, trzy lub nawet pięć. Nawiasem mówiąc, u zarania projektowania tak było. Ale sprawdzone podejście to dwa koła. Ale obecne oczywiste podejście przeszło przez ból i błędy:

Zazwyczaj szablon nie jest kompletnym rozwiązaniem, które można bezpośrednio przekonwertować na kod, jest to tylko przykład dobrego rozwiązania problemu, który można wykorzystać w różnych sytuacjach.

Wzorce zorientowane obiektowo pokazują relacje i interakcje między klasami lub obiektami , bez określania, które końcowe klasy lub obiekty aplikacji zostaną użyte.

1.2 Historia wzorców projektowych

Jeszcze w latach 70. programiści stanęli przed koniecznością tworzenia dużych programów, nad którymi musiały pracować całe zespoły programistyczne. Próbowano różnych metod organizacji pracy, ale największy wpływ na rozwój miało budownictwo.

Do zorganizowania pracy dużej grupy osób wykorzystano praktyki i podejścia z branży budowlanej. Nawiasem mówiąc, stamtąd do programowania weszły takie terminy, jak asembler (kompilacja), programista (konstruktor) i koncepcja architektury.

I jak już można się domyślić, idea wzorca projektowego została zaczerpnięta również z branży budowlanej. Pojęcie wzorców zostało po raz pierwszy opisane przez Christophera Alexandra w The Pattern Language. Miasta. Budynek. Budowa". W tej książce do opisu procesów projektowania miast użyto specjalnego języka, wzorców.

Wzorce w budownictwie opisywały typowe, sprawdzone w czasie decyzje: jaka powinna być wysokość okien, ile pięter ma mieć budynek, ile powierzchni w dzielnicy należy przeznaczyć na drzewa i trawniki.

Nic więc dziwnego, że w 1994 roku ukazała się książka „Techniki projektowania obiektowego. Wzorce projektowe”, który obejmuje 23 wzorce rozwiązujące różne problemy projektowania obiektowego.

Książka została napisana przez 4 autorów: Ericha Gammę, Richarda Helma, Ralpha Johnsona i Johna Vlissidesa. Tytuł książki był zbyt długi, by ktokolwiek mógł go zapamiętać. Dlatego wkrótce wszyscy zaczęli nazywać to „książką z gangu czterech”, czyli „książką z gangu czterech” , a potem nawet „książką GoF”.

Od tego czasu odkryto inne wzorce projektowe. Podejście „wzorcowe” stało się popularne we wszystkich obszarach programowania, więc teraz poza projektowaniem obiektowym można znaleźć wszelkiego rodzaju wzorce.

Ważny! Wzorce to nie jakieś superoryginalne rozwiązania, a wręcz przeciwnie, często spotykane, typowe rozwiązania tego samego problemu. Dobre sprawdzone rozwiązania.

1.3 Lista wzorów

Wielu programistów w całym swoim życiu nie nauczyło się ani jednego wzorca, co jednak nie przeszkadza im w ich stosowaniu. Jak powiedzieliśmy wcześniej, wzorce to dobre sprawdzone rozwiązania, a jeśli programista nie jest głupcem, to z doświadczeniem sam znajduje takie rozwiązania.

Ale po co przez dziesiątki prób i błędów dochodzić do optymalnych rozwiązań, skoro są ludzie, którzy już tę drogę przeszli i napisali książki z kwintesencją swojego doświadczenia i życiowej mądrości?

Możesz wbić gwóźdź kluczem, ale po co? Możesz nawet użyć wiertarki, jeśli bardzo się postarasz. Ale dobre, świadome posiadanie instrumentu jest właśnie tym, co odróżnia profesjonalistę od amatora. A profesjonalista wie, że główna cecha wiertła wcale nie jest w tym. Po co więc znać wzorce?

• Sprawdzone rozwiązania. Spędzasz mniej czasu, korzystając z gotowych rozwiązań, zamiast wymyślać koło na nowo. Niektóre decyzje możesz wymyślić sam, ale wiele z nich może być dla Ciebie odkryciem.
• Standaryzacja kodu. Podczas projektowania robisz mniej błędów w obliczeniach, używając typowych zunifikowanych rozwiązań, ponieważ wszystkie ukryte w nich problemy zostały już dawno znalezione.
• Ogólny słownik programowania. Mówisz nazwę wzorca, zamiast spędzać godzinę na wyjaśnianiu innym programistom, jaki fajny projekt wymyśliłeś i jakie klasy są do tego potrzebne.

Jakie są wzorce?

Wzorce różnią się poziomem złożoności, szczegółowością i pokryciem projektowanego systemu. Posługując się analogią do budownictwa, można zwiększyć bezpieczeństwo skrzyżowania stawiając sygnalizację świetlną lub zastąpić skrzyżowanie całym węzłem samochodowym z przejściami podziemnymi.

Najbardziej niskopoziomowe i najprostsze wzorce to idiomy. Nie są uniwersalne, ponieważ mają zastosowanie tylko w ramach jednego języka programowania.

Najbardziej wszechstronne są wzorce architektoniczne, które można zaimplementować w niemal każdym języku. Są one potrzebne do zaprojektowania całego programu, a nie jego poszczególnych elementów.

Ale najważniejsze jest to, że wzory różnią się przeznaczeniem. Wzorce, z którymi się zapoznamy, można podzielić na trzy główne grupy:

• Wzorce tworzenia dbają o elastyczne tworzenie obiektów bez wprowadzania zbędnych zależności do programu.
• Wzorce strukturalne pokazują różne sposoby budowania relacji między obiektami.
• Wzorce zachowań dbają o sprawną komunikację między obiektami.

1.4 Wprowadzenie do UML-a

Zacznijmy od przyjrzenia się tym samym 23 wzorcom, które zostały opisane w książce Gang of Four. Zarówno same wzorce, jak i ich nazwy są znane nawet początkującemu programiście. Przedstawię Ci je, ale gorąco polecam przeczytanie właśnie tej książki o wzorach.

Wzorce projektowe nie są powiązane z konkretnym językiem programowania, więc do ich opisu zwykle używany jest język UML. Był bardzo popularny 20 lat temu, ale nawet teraz jest czasami używany. A tak przy okazji, opis wzorców to właśnie miejsce, w którym stosowanie UML jest standardem.

Za pomocą języka UML można opisywać relacje między różnymi podmiotami. W naszym przypadku są to obiekty i klasy.

Relacje między klasami opisują cztery rodzaje strzałek:

	kompozycja (kompozycja) - podgatunek skupienia, w którym „części” nie mogą istnieć w oderwaniu od „całości”.
	agregacja – opisuje relację „część” – „całość”, w której „część” może istnieć oddzielnie od „całości”. Romb jest wskazany od „całej” strony.
	zależność – zmiana w jednym podmiocie (niezależnym) może wpłynąć na stan lub zachowanie innego bytu (zależnego). Niezależna jednostka jest wskazana z boku strzałki.
	uogólnienie - relacja dziedziczenia lub implementacja interfejsu. Po stronie strzałki znajduje się nadklasa lub interfejs.

W rzeczywistości wszystko jest tutaj bardzo proste. Ostatnia strzałka faktycznie oznacza, że ​​jedna klasa jest dziedziczona z innej klasy. A pierwsza i druga strzałka wskazują, że jeden obiekt przechowuje łącze do drugiego obiektu. I to wszystko.

Jeśli romb połączenia jest czarny, oznacza to, że połączenie jest słabe: obiekty mogą istnieć bez siebie. Jeśli romb jest biały, oznacza to, że obiekty są ze sobą silnie powiązane, na przykład klasa HttpRequesti jej klasa potomna HttpRequest.Builder.

1.5 Lista wzorów

Rodzaje wzorów będą oznaczone różnymi kolorami i literami:

B- behawioralny (behawioralny);

C- generujące (twórcze);

S- strukturalny (strukturalny).

I na koniec lista 23 wzorców projektowych: