Wzorzec projektowy (informatyka)
Wzorzec projektowy (ang. design pattern) – uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiających się, powtarzalnych problemów projektowych. Pokazuje powiązania i zależności pomiędzy klasami oraz obiektami i ułatwia tworzenie, modyfikację oraz utrzymanie kodu źródłowego. Jest opisem rozwiązania, a nie jego implementacją. Wzorce projektowe stosowane są w projektach wykorzystujących programowanie obiektowe.
Historia
Wzorce projektowe w informatyce wywodzą się z wzorców projektowych w architekturze, które zostały zaproponowane przez austriackiego architekta Christophera Alexandra[1][2] i miały ułatwić konstruowanie mieszkań i pomieszczeń biurowych. Pomysł ten nie został jednak przyjęty.
Inaczej stało się w informatyce. Termin wzorca projektowego został wprowadzony do inżynierii oprogramowania przez Kenta Becka oraz Warda Cunninghama w 1987 roku. Na konferencji OOPSLA, przedstawili oni wyniki swojego eksperymentu dotyczącego ich zastosowania w programowaniu. Został spopularyzowany w 1995 przez Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson oraz John Vlissides) dzięki książce Wzorce projektowe: Elementy oprogramowania obiektowego wielokrotnego użytku[3].
Wzorce rozwiązań
Wzorce projektowe najczęściej tworzone są w oparciu o programowanie obiektowe. Zakres tego pojęcia stał się problemem rozważanym od połowy lat 90. XX wieku. Ostatecznie ustalono, że algorytmy nie są wzorcami projektowymi, jako że rozwiązują problemy obliczeniowe, a nie projektowe. Wzorce często są łączone w celu rozwiązania bardziej złożonego problemu.
Zamiast skupiać się na funkcjonowaniu poszczególnych elementów, wzorce projektowe stanowią abstrakcyjny opis zależności pomiędzy klasami, co w efekcie wprowadza pewną standaryzację kodu oraz zwiększa jego zrozumiałość, wydajność i niezawodność. Wartość wzorców projektowych stanowi nie tylko samo rozwiązanie problemu, ale także dokumentacja, która wyjaśnia cel, działanie, zalety danego rozwiązania, co pomaga w łatwiejszym stosowaniu i adaptacji wzorców w danym zastosowaniu.
Wzorce projektowe mogą przyspieszyć proces rozwoju oprogramowania przez dostarczenie wypróbowanych rozwiązań dla problemów, które mogą nie być oczywiste na początku procesu projektowego. Często zagadnienia te wiążą się z ewolucją oczekiwań względem projektowanego systemu: rozszerzeniem jego funkcjonalności, zmianą sposobu i formatu wprowadzanych danych czy dostosowaniem aplikacji do różnych klas użytkowników. Nieuwzględnienie ich na początku procesu rozwoju produktu programistycznego powoduje często konieczność gruntownego przebudowywania zaawansowanego lub gotowego już oprogramowania.
Wzorzec MVC[4]
MVC (od angielskich słów Model, View i Controller) opracowano pod koniec lat 70 jako wzorzec realizacji interfejsu użytkownika w języku Smalltalk-80. Następnie wykorzystano go również w innych językach i systemach zorientowanych obiektowo.
Trzy składowe tego modelu to:
- Model - Główny nacisk kładzie na logikę aplikacji i logikę biznesową. Model powinien być zaprojektowany w taki sposób, aby był niezależny od wybranego rodzaju prezentacji oraz systemu obsługi akcji użytkownika.
- Widok - zarządza graficzną lub tekstową prezentacją modelu. Widok pobiera informacje z modelu, ilekroć zostaje powiadomiony o jego zmianie.
- Kontroler - jest odpowiedzialny za reagowanie na akcji użytkownika (np. kliknięcia myszką), odwzorowując je na operacje zawarte w modelu oraz na zmiany widoku.
Elementy wzorca
Wzorzec projektowy składa się z czterech podstawowych elementów:
- nazwy wzorca;
- problemu – opisuje sposoby rozpoznawania sytuacji, w których możemy zastosować dany wzorzec oraz warunki jakie muszą zostać spełnione, by jego zastosowanie miało sens;
- rozwiązania – opisuje elementy rozwiązania: ich relacje, powiązania oraz obowiązki, zawiera także wskazówki implementacyjne dla różnych technologii;
- konsekwencji – zestawienie wad i zalet stosowania wzorca, uwzględniające informacje o jego brakach oraz kosztach rozwoju i utrzymania systemu wykorzystującego dany wzorzec.
Dokumentacja
Dokumentacja wzorca projektowego powinna zawierać informacje o rozwiązywanym problemie, kontekst w jakim należy go stosować oraz sugerowane rozwiązanie. Różni autorzy mogą stosować odmienne style tworzenia takiej dokumentacji, ale zwykle jej najważniejsze elementy są do siebie podobne. Jeden z najpopularniejszych układów opisu wzorca projektowego został zaproponowany przez Bandę Czterech[5]
- Nazwa wzorca oraz klasyfikacja: opisowa oraz unikalna nazwa, umożliwiająca identyfikację oraz odwoływanie się do wzorca; klasyfikacja według jednego ze schematów.
- Przeznaczenie: opis celu, który stoi za wzorcem oraz powody, jakimi należy się kierować podczas jego wyboru.
- Inne nazwy: jeżeli istnieją inne, dobrze znane nazwy wzorca, należy je podać.
- Motywacja: scenariusz zawierający problem powiązany z kontekstem, w którym wzorzec może być stosowany.
- Stosowalność: sytuacje, w których wzorzec może być użyteczny.
- Struktura: graficzna reprezentacja wzorca, zwykle jako diagram klas lub diagram interakcji.
- Uczestnicy: lista klas i obiektów stosowanych w tym wzorcu oraz ich zobowiązania.
- Współpraca: opis wzajemnej interakcji klas i obiektów wykorzystywanych we wzorcu.
- Konsekwencje: wykaz wyników, efektów ubocznych oraz kompromisów jakie występują podczas użycia wzorca.
- Implementacja: wskazówki dotyczące implementacji wzorca; zwrócenie uwagi na specyficzne kwestie.
- Przykładowy kod: przykład zastosowania wzorca z wykorzystaniem jednego z języków programowania.
- Przykłady zastosowania: znane przykłady zastosowania wzorca w rzeczywistych programach.
- Pokrewne wzorce: odniesienie wzorca do innych, z którymi wiąże się przez wspólne stosowanie lub można go z nimi zamienić oraz przedstawienie różnic w stosunku do podobnych wzorców.
Klasyfikacja podstawowa
Początkowo Banda Czterech założyła, że istnieją dwa podstawowe rodzaje klasyfikacji wzorców[6]. Pierwsza z nich dotyczy rodzaju wzorca i opisuje to, co on robi. Według tego kryterium wzorce możemy podzielić na trzy rodziny:
- kreacyjne (konstrukcyjne) – opisujące proces tworzenia nowych obiektów; ich zadaniem jest tworzenie, inicjalizacja oraz konfiguracja obiektów, klas oraz innych typów danych[7];
- strukturalne – opisujące struktury powiązanych ze sobą obiektów;
- czynnościowe (behawioralne, operacyjne[8]) – opisujące zachowanie i odpowiedzialność współpracujących ze sobą obiektów.
Drugi model dzieli wzorce na kategorie według ich zakresów. Kategoryzacja polega na określeniu czy wzorzec dotyczy klas, czy obiektów. Tutaj wzorce dzielimy na:
- klasowe – opisujące statyczne związki pomiędzy klasami;
- obiektowe – opisujące dynamiczne związki pomiędzy obiektami.
Uwzględniając powyższe założenia klasyfikacja podstawowych wzorców wygląda następująco:
- wzorce kreacyjne:
- Budowniczy (obiektowy),
- Fabryka abstrakcyjna (obiektowy),
- Metoda wytwórcza (klasowy),
- Prototyp (obiektowy),
- Singleton (obiektowy);
- wzorce strukturalne:
- wzorce czynnościowe/operacyjne:
- Łańcuch zobowiązań/odpowiedzialności (obiektowy),
- Polecenie (obiektowy),
- Interpreter (klasowy),
- Iterator (obiektowy),
- Mediator (obiektowy),
- Pamiątka/Memento (ang. Memento) (obiektowy),
- Metoda szablonowa (ang. template method) (klasowy),
- Obserwator (obiektowy),
- Stan (obiektowy),
- Strategia (obiektowy),
- Odwiedzający/Wizytator (ang. visitor) (obiektowy),
- Zabór Zasobu Jest Inicjalizacją (obiektowy).
Klasyfikacja rozszerzona
W późniejszym okresie pojawiły się inne kategorie wzorców projektowych:
- wzorce współbieżności – definiują sposoby współdziałania wielu obiektów, wątków lub procesów; zaliczany do nich:
- Aktywny obiekt,
- Asynchroniczne sterowanie przez zdarzenia,
- Udaremnianie (rozgraniczanie),
- Blokada z podwójnym zatwierdzaniem,
- Ochraniane wstrzymywanie,
- Obiekt monitorujący,
- Blokada zapisu i odczytu,
- Zarządca procesów,
- Pula wątków,
- Pamięć dla wątków,
- Reaktor;
- Wzorce odwzorowania O-R – opisują (między innymi) wymianę danych pomiędzy warstwą danych a warstwą logiki biznesowej:
- Leniwa inicjalizacja.
- Pozostałe wzorce
Zobacz też
- wzorzec architektoniczny
- antywzorzec projektowy
Linki zewnętrzne
Przypisy
- ↑ Alexander, Christopher, The Timeless Way of Building, Oxford University Press, 1979, ISBN 978-0-19-502402-9.
- ↑ Alexander Christopher, Sara Ishikawa, Murray Silverstein, The Pattern Language: Towns, Buildings, Construction, Oxford University Press, 1977, ISBN 978-0-19-501919-3.
- ↑ Tytuł oryginalny: „Design Patterns: Elements of Reusable Object-Oriented Software, ISBN 978-0-201-63361-0.
- ↑ Barbara Filipczyk, Jerzy Gołuchowski, Tworzenie aplikacji internetowych : praca zbiorowa, Katowice: Wydawnictwo Akademii Ekonomicznej im. Karola Adamieckiego, 2008, ISBN 978-83-7246-449-1, OCLC 316477849 [dostęp 2020-09-20].
- ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Inżynieria oprogramowania: Wzorce projektowe (Wyd. II). Warszawa: WNT, 2008, s. 7–9. ISBN 978-83-204-3472-9.
- ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Inżynieria oprogramowania: Wzorce projektowe (Wyd. II). Warszawa: WNT, 2008, s. 12. ISBN 978-83-204-3472-9.
- ↑ Christopher G. Lasater: Design Patterns. Wordware Publishing (Jones and Bartlett Publishers), 2007, s. 302. ISBN 978-1-59822-031-5.
- ↑ 1.5 Struktura katalogu. W: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Wzorce projektowe. Helion, 2010, s. 24. ISBN 978-83-246-2662-5.
Bibliografia
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Inżynieria oprogramowania: Wzorce projektowe (Wyd. II). Warszawa: WNT, 2008. ISBN 978-83-204-3472-9.
- Christopher G. Lasater: Design Patterns. Wordware Publishing (Jones and Bartlett Publishers), 2007, s. 302. ISBN 978-1-59822-031-5.