Wzorce projektowe

Tworząc oprogramowanie często wykorzystuje się podobne lub identyczne rozwiązania. Możliwość wielokrotnego zastosowania kodu źródłowego stanowiące implementację rozwiązania powtarzającego się problemu w wielu aplikacjach jest pożądana ze względu na:

· używanie kodu, którego implementacja w innej aplikacji została już sprawdzona w środowisku produkcyjnym

· skrócenie czasu tworzenia oprogramowania

· ujednolicenie oprogramowania

 

Implementację wzorcowego rozwiązania zawsze można udostępnić w postaci biblioteki, która może być wykorzystywana przez wiele aplikacji.

Należy zauważyć, że podobieństwo rozwiązań problemów inżynierii oprogramowania nie musi wynikać jedynie z identycznego kodu źródłowego (ciąg instrukcji). Wiele aplikacji może stosować podobne rozwiązanie, które poprzez uogólnienie kodu źródłowego można ujednolicić.

 

 

Wzorce umożliwiają wykorzystanie sprawdzonych i ujednoliconych rozwiązań dla powtarzających się problemów w różnych projektach oprogramowania. Wyróżniono różne klasy wzorców stosowanych w inżynierii oprogramowania, które mogą być stosowane w odpowiednich etapach tworzenia oprogramowania:

· architektoniczne – poziom integracji komponentów oprogramowania

· analityczne – poziom odwzorowania rzeczywistości

· projektowe – poziom interakcji pomiędzy obiektami i klasami

· implementacyjne – poziom jężyka oprogramowania

· testowe – poziomy i sposoby diagnostyki oprogramowania

 

Należy zauważyć, że wzorce projektowe są definiowane na wysokim poziomie abstrakcji, a dzięki uogólnieniom możliwe jest ich stosowanie w różnych projektach. Dlatego zastosowanie wzorca projektowego tworzy szkielet (architekturę kodu), ale nie zawiera szczegółów związanych z tematyką projektu.

 

 

Geneza pojęcia wzorca projektowego wywodzi się z architektury, pierwsza definicja została przedstawiona w książce „A pattern Language: Towns, Buildings, Construction” autorstwa architekta Christophera Alexandra opublikowanej w 1977 roku.

 

Wzorzec opisuje problem, który powtarza się wielokrotnie w danym środowisku oraz podaje istotę jego rozwiązania w taki sposób, aby można było je stosować milion razy bez potrzeby powtarzania tej samej pracy.

 

Przedstawiona definicja jest uniwersalna i można ją stosować dla potrzeb tworzenia oprogramowania. Zgodnie z definicją dla każdego wzorca można wyróżnić problem (lub grupę problemów) jaki on rozwiązuje oraz wyróżnić cel jaki zostaje osiągnięty przy jego zastosowaniu.

 

Należy zwrócić uwagę na wysoki poziom abstrakcji zarówno przy opisie środowiska w jakim rozwiązanie jest stosowane oraz przy określeniu celu zastosowania wzorca.

 

 

Elastyczne i ujednolicone reguły interakcji pomiędzy obiektami, które stanowią powtarzalne rozwiązanie zagadnień projektowych oprogramowania tworzą wzorzec projektowy, który:

· nie jest zależny od języka programowania i zwiększa czytelność kodu

· pozwala wykorzystać elastyczny sposób zapisu obiektowego kodu w wielu projektach oprogramowania

· jest opisem „architektury zastosowania rozwiązania” stosowanym przez wielu programistów, wprowadzając ujednolicone nazewnictwo

 

Najczęściej stosowane i najbardziej przydatne przy tworzeniu oprogramowania reguły interakcji pomiędzy obiektami zostały opisane w literaturze tworząc katalog wzorców projektowych. Każdy skatalogowany wzorzec projektowy został opracowany jako rozwiązanie określonej grupy problemów inżynierii oprogramowania.

Dobór właściwego wzorca projektowego wymaga poprawnego rozpoznania problemu inżynierii oprogramowania, a jego zastosowanie w oprogramowaniu wymaga stworzenia kodu źródłowego zgodnie z regułami określonymi przez implementowany wzorzec projektowy.

 

Zastosowanie wzorca projektowego nie ogranicza się do implementacji pojedynczej klasy czy interfejsu. Zastosowanie wzorca projektowego nie zależy od tematyki projektu. Wzorzec projektowy nie ustala także nazw dla implementowanych klas i interfejsów.

 

Każdy wzorzec projektowy posiada:

· zakres zastosowań wyznaczony przez cel, przy czym obszar zastosowań kilku wzorcy projektowych może się pokrywać

· reguły konstruowania kodu, uwzględniające m.in.:

            - klas i interfejsów i ich lokalizację w pakietach

            - lokalizację i sygnatury metod (deklaracje i definicje)

            - zależności pomiędzy różnymi obiektami

            - podział odpowiedzialności dla poszczególnych obiektów

· indywidualną charakterystykę (cechy), w szczególności należy zwrócić uwagę na elastyczność, która umożliwia późniejszą rozbudowę bez konieczności wprowadzania zmian w pozostałej części kodu (tzw. Kod klienta stosującego wzorzec projektowy). Niestety pozostały kod projektu nie może być zmieniany np. ze względu na brak kodu źródłowego.

 

Kanoniczny katalog wzorców projektowych

Pierwszą publikacją w której przedstawiono katalog wzorców projektowych stosowanych przy tworzeniu oprogramowania była książka „Design Patterns – Elements of Reusable Software” opublikowana w 1995 roku przez czterech autorów: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.

 

Autorzy wymienionej książki, znani także jako „banda czworga” – GoF (Gangn of Four), przedstawili następującą definicję wzorca projektowego:

„Wzorzec projektowy identyfikuje i opisuje pewną abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji pojedynczej klasy, instancji lub komponentu”.

 

Opublikowany przez GoF kanoniczny katalog uwzględniał 23 wzorce projektowe, które zostały podzielone na trzy rozłączne kategorie:

· kreacyjne (konstrukcyjne)

· strukturalne

· behawioralne (czynnościowe)

 

 

Wzorce projektowe konstrukcyjne umożliwiają uniezależnienie systemu od sposobu tworzenia obiektów.

Wśród wzorców można wyróżnić:

· Abstract Factory (abstrakcyjna fabryka)

· Factory Method (metoda fabrykująca/wytwórcza)

· Builder (budowniczy)

· Prototype (prototyp)

· Singleton

 

Konstrukcyjne wzorce projektowe

● Zastosowanie w kodzie konstrukcyjnego wzorca projektowego dla powołanych instancji obiektów bezpośrednio wynika z cech jakie wzorzec zapewnia

● Odpowiednio dobrany wzorzec konstrukcyjny umożliwia tworzenie elastycznego kodu dedykującego odpowiedzialność za tworzenie instancji powoływanych do poszczególnych klas, ich metod i konstruktorów

● Dalszy rozwój oprogramowania może wymusić zmianę projektowego wzorca konstrukcyjnego zastosowanego przy powoływaniu nowych obiektów klas

● Ze względu na wysoki poziom abstrakcji dobór wzorca projektowego lub identyfikacja w kodzie jest utrudniona i wymaga praktyki. Zaleca się stosowanie nazewnictwa interfejsów, klas, konstruktorów i metod ułatwiających identyfikację zastosowanego wzorca

● Stosowane w kodzie wzorce projektowe zwykle należą do kanonicznego katalogu wzorców, jednak programiści przy wytwarzaniu kodu stosują także wzorce projektowe spoza kanonicznego katalogu

 

 

Wzorce projektowe strukturalne pomagają łączyć obiekty w większe struktury, umożliwiają elastyczne wykorzystanie dziedziczenia i kompozycji:

· Adapter

· Bridge (most)

· Composite (kompozyt)

· Decorator (dekorator)

· Facade (fasada)

· Flyweight (waga piórkowa/pyłek)

· Proxy (pośrednik)

 

 

Wzorce projektowe czynnościowe pomagają zdefiniować interakcję i komunikację pomiędzy obiektami oraz przydział odpowiedzialności.

Wyróżniono:

· Chain of Responsibility (łańcuch odpowiedzialności)

· Command (polecenie)

· Interpreter

· Iterator

· Mediator

· Memento (pamiątka)

· Observer (obserwator)

· State (stan)

· Strategy (strategia)

· Template Method (szablon)

· Visitor (wizytator)