Wprowadzenie do Wzorców Projektowych

Aleksander Byrski

Katedra Informatyki
Akademia Górniczo-Hutnicza w Krakowie
olekb@agh.edu.pl

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 1 / 50
 Spis treści

Wstep.
˛
Wzorce projektowe (studium przypadku).
Wzorce architektoniczne.
Antywzorce.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 2 / 50
 Bibliografia

A. Shalloway, J.R. Trott, „Design Patterns Explained - A New

Perspective on Object-Oriented Design”, Addison Wesley 2001.
E. Gamma, R. Helm, R. Johnson, J. Vlissides (Gang of Four),
„Design Patterns - Elements of Reusable Object-Oriented
Software”, Addison Wesley 1998.
F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal
„Pattern-oriented Software Architecture”, John Wiley 1996.
W. Brown, R. Malveau, T. Mowbray „Anti Patterns, Refactoring
Software Architectures and Projects in Crisis”, Wiley 1998.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 3 / 50
 Motto

Dobry naukowiec, to osoba, która posiada mnóstwo oryginalnych

pomysłów.

Dobry inżynier, to osoba, która tworzy działajacy

˛ projekt przy pomocy
jak najmniejszej liczby oryginalnych pomysłów.

– Freeman Dyson

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 4 / 50
 Wprowadzenie

Co to jest wzorzec projektowy?

Szablon klasy, funkcji?
Szkielet napisany w C++ w który można wstawić własny kod?
Czy tylko w informatyce maja˛ zastosowanie wzorce projektowe?

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 5 / 50
 Christopher Alexander i wzorce projektowe

W latach 70-tych prace Alexander’a o konieczności zmiany

obowiazuj
˛ acego
˛ paradygmatu w architekturze i wzorcach
architektonicznych.
Ponadczasowy sposób budowania (timeless way of building) –
„niezmiennik procesów budowania, pozwalajacych
˛ tworzyć
budynki, które sa˛ żywe”.
Jakość bez nazwy (the quality without a name) – „Istnieje
centralna jakość, która jest podstawowym kryterium życia i ducha
w człowieku, mieście, budynku lub naturze. Jakość ta jest
obiektywna i precyzyjna, lecz nie może zostać nazwana. Jest to
najbardziej podstawowa jakość wszystkiego”.
Określenia jakości bez nazwy: żywy, cały, wygodny, wolny,
dokładny, bezosobowy, wieczny.
Inna definicja: „subtelna wolność od wewnetrznych
˛ sprzeczności”.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 6 / 50
 „Każdy wzorzec określa problem, który wielokrotnie wystepuje
˛ w
naszym środowisku, a nastepnie
˛ opisuje zasadnicza˛ cz˛eść
rozwiazania
˛ tego problemu w taki sposób, by można było użyć
tego rozwiazania
˛ milion razy, ale nigdy dwa razy tak samo”
Architektoniczne wzorce projektowe:
Budowa wejścia do łazienki z przedpokoju a nie np. z kuchni.
Budowa „ślepej” kuchni a nie np. „ślepego” pokoju.
Budowa placu zabaw w centrum osiedla a nie na obrzeżach.
Literackie wzorce projektowe:
Nieszcz˛eśliwa miłość w romansach.
W kryminałach: zabójca˛ jest najmniej podejrzany.
Wyprawa w celu zniszczenia zła w literaturze fantasy.
mesjanizm, wallenrodyzm i inne „izmy” w literaturze. romantycznej.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 7 / 50
 Wzorzec projektowy

Ogólne rozwiazanie
˛ cz˛esto spotykanego problemu w
specyficznym przypadku.
Wzorce powstaja˛ z doświadczenia ekspertów w danej dziedzinie.
Podstawowe elementy opisu wzorca:
nazwa – używana w celu jednoznacznej identyfikacji, uwspólnienia
jezyka,
˛
problem – opis problemu, który może być rozwiazany,
˛ lista
warunków, które musza˛ być spełnione, aby stosowanie wzorca
miało sens
rozwiazanie
˛ – elementy składajace
˛ sie˛ na projekt, ich zwiazki,
˛
zobowiazania
˛ i współprace,
˛ nie opisuje konkretnego projektu –
stanowi pewien szablon
konsekwencje – zyski i straty, wady i zalety stosowania wzorca.
Wzorzec stanowi pewnego rodzaju forme,
˛ z którego powstaje
gotowy moduł systemu (np. komponent).

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 8 / 50
 Zyski ze stosowania wzorców

Wynikaja˛ z wielu praktycznych doświadczeń.

Tworza˛ popularny w środowisku inżynierów słownik pojeć.
˛
Sprawiaja,
˛ że projekty sa˛ bardziej przejrzyste dla nowicjuszy.
Upraszczaja˛ restrukturyzacje˛ istniejacych
˛ projektów.
Umożliwiaja˛ wielokrotne użycie sprawdzonych rozwiaza
˛ ń.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 9 / 50
 Kategorie wzorców

Wzorce architekturalne – wysokopoziomowa definicja struktury

aplikacji, opis podsystemów, ich odpowiedzialności, relacji.
Wzorce projektowe – niezależne od implementacji wskazówki
odnośnie budowy cz˛eści systemu.
Idiomy – najwcześniejszy przykład wzorca, niskopoziomowe opisy
implementacji odpowiednich komponentów, lub nawet wzorców
projektowych w danym jezyku.
˛
Antywzorce – niedawno powstałe przykłady cz˛esto stosowanych
złych rozwiaza
˛ ń wraz z receptami rozwiazania
˛ problemów.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 10 / 50
 Klasyfikacja wzorców wymienionych w ksiażce
˛ GoF

Strukturalne
Zastosowanie: Łaczenie
˛ istniejacych
˛ obiektów.
Przykłady: Adapter, Decorator, Facade, Composite, Bridge, Proxy,
Flyweight.
Behawioralne
Zastosowanie: Umożliwianie elastycznych zmian zachowania.
Przykłady: Interpreter, Iterator, Chain of responsibility, Mediator,
Template method, Observer, Visitor, Memento, Command, State,
Strategy.
Kreacyjne
Zastosowanie: Ułatwianie tworzenia obiektów
Przykłady: Builder, Abstract factory, Factory method, Prototype,
Singleton.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 11 / 50
 Wzorce projektowe – studium przypadku

Wzorce odpowiadaja˛ zwykle wycinkom dziedziny problemu.

Używajac˛ wzorców można oczywiście zbudować złożona˛
aplikacje˛ (jest to nawet wskazane).
Ksiażka
˛ GoF prezentuje interesujacy
˛ przykład aplikacji stworzonej
w oparciu o wzorce – edytor WYSIWYG.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 12 / 50
 Struktura dokumentu

Dokument składa sie˛ z

rekursywnie komponowanych
cz˛eści
Kolumna zawiera paragrafy,
paragrafy zawieraja˛ wiersze,
rysunki, tabele, wiersz może
zawierać również rysunki
oraz oczywiście litery.
Wiersz może być
postrzegany jako element
złożony z innych (być może z
innych wierszy).

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 13 / 50
 Rekurencyjna kompozycja

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 14 / 50
 Wzorzec Composite

Problem: złożenie obiektów w strukture˛ drzewiasta,

˛ całości i
cz˛eści powinny być podobnie traktowane.
Rozwiazanie:
˛ agregacja nadklasy w klasie potomnej.
Konsekwencje: klient operujac ˛ na obiekcie może nie być
świadomy że jest to kompozyt. Klient może w prosty sposób
obsługiwać obiekty i kompozyty. Łatwo dodaje sie˛ nowe klasy.
Kompozyt zawierać może WSZYSTKIE obiekty.
Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza
Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 15 / 50
 Formatowanie

Elementy składowe tekstu maja˛ być odpowiednio formatowane

(tekst łamany w linie, linie w kolumny, rysunki powinny być
centrowane w kolumnach itp).
Powinno być możliwe dodawanie nowych algorytmów
formatowania niezależnie od istniejacych,
˛ badź
˛ dodawanych
nowych elementów tekstu.
Zmiana algorytmów formatowania powinna być prosta w czasie
kompilacji (przy użyciu IoC można również po kompilacji).

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 16 / 50
 Ogólna akcja, szczególne wykonanie

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 17 / 50
 Wzorzec Strategy

Problem: konieczność definicji rodziny wymienialnych algorytmów.

Rozwiazanie:
˛ deklaracja ogólnej akcji, definicja w klasach potomnych.
Konsekwencje: Dziedziczenie pomaga w wydzieleniu wspólnej funkcjonalności algorytmu.
Zastapienie
˛ polimorfizmem złożonych instrukcji warunkowych. Można dostarczyć wiele
implementacji tego samego zachowania. Klient musi znać strategie przed użyciem.
Wiekszość
˛ parametrów przekazywanych przez Kontekst może nie być użyteczna dla
wszystkich strategii.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 18 / 50
 Upiekszanie
˛ interfejsu

Konieczne jest dodanie elementów usprawniajacych

˛ edycje˛ tekstu
(np. suwak do przesuwania strony, ramka ograniczajaca
˛ strone˛
tekstu).
Nie powinno używać sie˛ dodawać tego typu elementów do
używanych elementów GUI za pomoca˛ dziedziczenia
(BorderComposition, ScrollableComposition,
ScrollableBorderComposition), aby nie stracić elastyczności.
Inne obiekty nie powinny być świadome istnienia tych usprawnień,
dzieki
˛ czemu bedzie
˛ można na nich operować w trakcie działania
systemu.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 19 / 50
 Wielokrotny agregat

enclosure). Agregat przesyła

wszystkie komunikaty
otrzymane z zewnatrz
˛ do
obiektu agregowanego,
dodajac
˛ ewentualnie swoje
zachowanie.
MonoGlyph może agregować
obiekty Glyph, co oznacza,
że może agregować również
swoje klasy potomne (np.
Border, Scroller), dlatego
łatwo jest zaimplementować
We wzorcu ma zastosowanie tekst z ramka˛ oraz z
koncepcja „przeźroczystego suwakiem, bez konieczności
zawierania” (transparent wielokrotnego dziedziczenia.
Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza
Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 20 / 50
 Wzorzec Decorator

Problem: konieczność dodania funkcjonalności bez zmiany własności obiektu.

Rozwiazanie:
˛ deklaracja wielokrotnego agregatu dodajacego
˛ swoja˛ funkcjonalność.
Konsekwencje: Wieksza
˛ elastyczność niż w przypadku dziedziczenia, można bez
problemu wielokrotnie ozdabiać elementy. Możliwość implementacji nieprzewidzianych
cech systemu. Dekorator nie jest tym samym co jego zawartość, choć tak samo sie˛ go
obsługuje.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 21 / 50
 Zmiana wygladu
˛ interfejsu

Stosowanie różnych managerów GUI wymaga zmiany wygladu

˛
(Motif, KDE itd).
Należy przewidzieć powstanie nowych standardów GUI i
umożliwić dostosowanie sie˛ do nich.
Zmiana wygladu
˛ aplikacji powinna być możliwa w trakcie jej
działania.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 22 / 50
 Abstrakcyjne tworzenie obiektów

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 23 / 50
 Konkretne produkty abstrakcyjnej fabryki

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 24 / 50
 Wzorzec Abstract factory

Problem: konieczność tworzenia rodziny obiektów (powiazanych

˛ ze soba˛ w pewien
sposób).
Rozwiazanie:
˛ stworzenie abstrakcyjnej fabryki oraz konkretnych fabryk dla konkretnych
rodzin obiektów.
Konsekwencje: Fabryka zdejmuje z klienta obowiazek ˛ poznania klas obiektów z których
korzysta. Łatwo można wymienić rodzine˛ obiektów. Wymusza używanie przez aplikacje˛
obiektów tylko z jednej rodziny. Tworzenie nowych produktów wymaga zmian w interfejsie
fabryki abstrakcyjnej i wszystkich fabryk konkretnych

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 25 / 50
 Pojedyncza instancja

Skad˛ można wziać

˛ referencje˛ do GUIFactory? Skadkolwiek:
˛ Może
to być globalna zmienna statyczna, lokalna zmienna (jeśli interfejs
jest obsługiwany przez jedna˛ klase).
˛
Można wykorzystać wzorzec Singleton, który utrzymuje wyłacznie
˛
jeden obiekt pewnej znanej klasy.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 26 / 50
 Wzorzec Singleton

Problem: konieczność utrzymania jednej, globalnie dostepnej

˛ instancji pewnej klasy w
systemie.
Rozwiazanie:
˛ stworzenie statycznej „fabryki” kontrolujacej
˛ tworzenie swoich instancji.
Konsekwencje: Pełna kontrola dostepu˛ do instancji. Brak konieczności deklaracji globalnej
zmiennej. Możliwe dziedziczenie i rozszerzenie funkcjonalności. Możliwa kontrola
tworzenia pewnej, skończonej liczby instancji. Singletony sa˛ trudno testowalne.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 27 / 50
 Przenośny interfejs użytkownika

Oprócz zmiany wygladu

˛ idealnie byłoby dostosować edytor do
standardów GUI implementowanych w różnych systemach.
Pakiety obsługujace
˛ GUI sa˛ podobne pod wzgledem˛
funkcjonalności (zmiana rozmiaru okna, maksymalizacja, menu
kontekstowe) ale nie ma gwarancji, że implementacja bedzie
˛
podobna (na pewno hierarchia klas bedzie
˛ różna).
Istnieje potrzeba definicji uniwersalnej hierarchii obsługi GUI i
spiecie
˛ jej z odpowiednia˛ konkretna˛ hierarchia˛ pakietu
odpowiadajacego˛ za tworzenie okien np. w Linux, Windows czy
Mac.
Nie można użyć Abstrac Factory, gdyż nie ma gwarancji że każda
wszystkie hierarchie GUI bed˛ a˛ kompatybilne.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 28 / 50
 Rysowanie elementów graficznych w oknie

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 29 / 50
 Rozdzielenie abstrakcji od implementacji

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 30 / 50
 Wzorzec Bridge

Problem: konieczność oddzielenia abstrakcji od implementacji.

Rozwiazanie:
˛ stworzenie hierarchii uniwersalnych klas oraz ich implementacji.
Konsekwencje: Implementacja jest oddzielona od interfejsu, może być rekonfiguorowana
nawet w czasie pracy systemu. System jest lepiej ustrukturalizowany, łatwo rozszerzalny.
Szczegóły implementacji ukryte sa˛ przed użytkownikiem.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 31 / 50
 Obsługa czynności

Czynności wykonywane przez użytkownika (open, save, load,

quit) powinny nie być zależne od interfejsu.
Potrzebna jest funkcjonalność typu UNDO/REDO.
Zatem wywołanie komendy z menu powinno odnosić sie˛ do
OBIEKTU a nie do FUNKCJI.
W ten sposób łatwo skonstruować historie˛ czynności.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 32 / 50
 Enkapsulacja czynności w klasie

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 33 / 50
 Wywołanie czynności z menu

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 34 / 50
 Historia czynnności

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 35 / 50
 Wzorzec Command

Problem: Implementacja wielu czynności, dodawania nowych, parametryzacji, logowania,

operacji undo.
Rozwiazanie:
˛ Enkapsulacja czynności w obiekcie.
Konsekwencje: Oddzielenie obiektu wywołujacego˛ usługe˛ od dostarczajacego
˛ ja.
˛ Możliwe
jest zastosowanie Composite w celu stworzenia makro-komendy. Można łatwo dodawać
nowe komendy – nie trzeba zmieniać istniejacych
˛ klas.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 36 / 50
 Adaptacja nieużytecznego interfejsu

Aplikacja powinna skorzystać z klasy, która nie spełnia

wymaganego interfejsu.
Sytuacja taka wystepuje
˛ cz˛esto, gdy mamy do czynienia z
zakupem bibliotek czy też komponentów.
Do dostosowania interfejsu służy wzorzec Adatper (zwany również
cz˛esto Wrapperem).
W zależności od uwarunkowań jezyka
˛ programowania, którego
używamy, należy użyć odpowiedniego typu wzorca Adapter
(Object Adapter – wykorzystujacy˛ kompozycje˛ lub Class Adapter
– wykorzystujacy
˛ dziedziczenie wielobazowe).

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 37 / 50
 Warianty wzorca adapter

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 38 / 50
 Wzorzec Adapter

Problem: konieczność dopasowania do systemu istniejacej

˛ klasy,
która nie spełnia wymaganego interfejsu.
Rozwiazanie:
˛ opakowanie interfejsu przy użyciu kompozycji lub
wielobazowego dziedziczenia.
Konsekwencje (Class adapter): Nie adaptuje klasy wraz z
podklasami. Istnieje możliwość zmiany niektórych zachowań
klasy adaptowanej (dzieki
˛ dziedziczeniu). Wykorzystuje jeden
obiekt, nie ma konieczności tworzenia dodatkowego powiazania.
˛
Konsekwencje (Object adapter): Dzieki ˛ kompozycji można
adaptować wiele klas jednocześnie, moga˛ to być również
podklasy, możliwe jest też dodanie nowych funkcjonalności.
Trudniej jest przysłonić metody klasy adaptowanej, choć w tym
momencie staje sie˛ to mniej potrzebne dzieki
˛ kompozycji.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 39 / 50
 Model-View-Controller

Jest to jeden z pierwszych wzorców projektowych, wykorzystany

po raz pierwszy w programach pisanych w jezyku
˛ Smalltalk
(poczatek
˛ lat 80-tych).
Problem: wysoce interaktywny system musi być rozszerzalny,
łatwy w utrzymaniu i obsługiwać wiele interfejsów użytkownika.
Rozwiazanie:
˛ należy użyć wzorca MVC w celu rozdzielenia
warstwy prezentacji, warstwy interakcji oraz modelu systemu.
MVC jest popularna˛ architektura˛ stosowana˛ w systemach z GUI,
istnieja˛ złożone frameworki (Struts, Spring MVC i in.).

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 40 / 50
 Model obiekt aplikacji, odzwierciedla logiczna˛ strukture˛
problemu. Gdy dane modelu sie˛ zmieniaja, ˛ model
powiadamia zależace˛ od niego widoki (aktualizacja).
Widok reprezentacja ekranowa, przedstawienie cz˛eści modelu w
sposób zrozumiały dla użytkownika, umożliwienie
ingerencji w jego treść.
Kontroler definicja sposobu w jaki interfejs użytkownika reaguje na
operacje wykonywane przez użytkownika, interpretacja
poleceń wydawanych np. za pomoca˛ myszki czy też
klawiatury, powiadamianie modelu.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 41 / 50
 Schemat MVC

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 42 / 50
 Zasada działania wzorca MVC

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 43 / 50
 Przykład wykorzystania wzorca MVC

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 44 / 50
 Konsekwencje stosowania MVC

Upraszcza projekt dzieki

˛ rozdzieleniu ról pomiedzy
˛ specjalnie
zdefiniowane moduły.
Pozwala na obsługiwaine wielu różnych widoków/wielu różnych
użytkowników.
Wspomaga implementacje˛ systemu, rozszerzalność oraz ułatwia
testowanie.
Ułatwia utrzymywanie kodu dzieki
˛ obniżeniu jego redundancji.
Umożliwia podział obowiazków
˛ programistów.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 45 / 50
 Architektura warstwowa (Layers)

Problem: konieczność strukturalizacji

aplikacji dekomponowalnej na grupy
podzadań określone na różnych
poziomach abstrakcji.
Rozwiazanie:
˛ wydzielić warstwy
abstrakcji, przydzielić im odpowiednia˛
funkcjonalność i zapewnić odpowiednia˛
komunikacje˛ miedzy
˛ nimi.
Konsekwencje: Warstwy moga˛ być
zamienione (inny algorytm, komponent)
bez wpływu na reszte˛ systemu. Warstwy
moga˛ być używane w różnych
kontekstach (pakować możemy różne
przedmioty, nie tylko rowery). Zależności
specyficzne dla warstw sa˛ lokalne (np.
wymagany zestaw narz˛edzi do
skrecania
˛ rowerów).
Przykłady: Architektura OSI/ISO.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 46 / 50
 Potoki i filtry (Pipes and filters)

Problem: konieczność obróbki

strumienia danych za pomoca˛ różnych
algorytmów.

Rozwiazanie:
˛ połaczenie
˛ programów
realizujacych
˛ algorytmy za pomoca˛
zunifikowanego interfejsu.

Konsekwencje: Możliwość wymiany

filtrów. Możliwość rekonfiguracji całej
obróbki strumienia (wstawienie
dodatkowych filtrów pomiedzy ˛ istniejace
˛
bez wpływu na pozostałe).

Przykłady: komunikacja
miedzyprocesowa
˛ w UNIX/Linux.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 47 / 50
 Tablica (Blackboard)

Rozwiazanie:
˛ umiejscowienie danych w
jednym miejscu w ustandaryzowanej
formie, umożliwienie podsystemom
(komponentom, agentom) pobieranie
danych, przetwarzanie ich i
umieszczanie wyników przetworzenia na
tablicy.
Konsekwencje: Łatwość zarzadzania
˛
tablica˛ ze wzgledu
˛ na całkowita˛
niezależność od operatorów. Na tablicy
nie umieszcza sie˛ informacji, które nie
pochodza˛ z analizy danych na niej
Problem: konieczność operacji na zawartych.
danych pochodzacych
˛ z różnych źródeł Przykłady: analiza danych w
bez spójnej strategii. środowiskach agentowych.

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 48 / 50
 Broker

Problem: poszukiwanie informacji w

wielu systemach, odciażenie
˛
użytkownika od konieczności
bezpośredniego dostepu.
˛
Rozwiazanie:
˛ wyspecjalizowany serwis
posiadajacy
˛ możliwość komunikacji z
wymaganymi systemami.
Konsekwencje: klient nie jest zależny od
źródeł informacji.
Przykłady: agentowe systemy aukcyjne,
poszukiwanie informacji (np. w
środowisku Web 3.0).

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 49 / 50
 Zakończenie

Projektować oprogramowanie można na dwa sposoby.

Pierwszy sposób: oczywiście projekt należy tak uprościć, aby nie było
w nim żadnych wad.

Drugi sposób: projekt należy tak skomplikować, aby nie było w nim
żadnych oczywistych wad.

Pierwsza metoda jest o wiele trudniejsza.

– C.A.R. Hoare

Aleksander Byrski ( Katedra Informatyki Akademia Górniczo-Hutnicza

Wzorce Projektowe
w Krakowie olekb@agh.edu.pl ) 50 / 50