Projektowanie obiektowe: Zasady i skad sie biora wzorce projektowe.

Projektowanie obiektowe: Zasady i skad sie biora wzorce projektowe.

Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Wykład 5
Projektowanie obiektowe: Zasady i
skad
˛ sie˛ biora˛ wzorce projektowe.
Inżynieria oprogramowania
MIS-1-502-s MIO-1-505-s MIS-1-505-n
Listopad 2014
Wprowadzenie
GRASP
Stosowanie zasad
Kazimierz Michalik
Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
5.1
Agenda
1
Wprowadzenie
2
GRASP
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Wprowadzenie
GRASP
Stosowanie zasad
3
Stosowanie zasad
5.2
Co to jest G.R.A.S.P.?
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
C. Larman: „Applying UML and Patterns”
„A Methodical Approach to Basic OO Design”.
„The GRASP principles or patterns are a learning aid to
help you understand essential object design and apply
design reasoning in a methodical, rational, explainable
way”.
Wprowadzenie
C. Larman: „Applying UML and Patterns”
GRASP
Stosowanie zasad
„Metodyczne podejście do podstaw projektowania
obiektowego.”.
„Zasady/wzorce GRASP sa˛ pomoca˛ w zrozumieniu istoty
projektowania obiektowego i stosowania go w metodyczny,
racjonalny i zrozumiały sposób".
5.3
Co to sa˛ wzorce projektowe?
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Wzorzec projektowy
uniwersalne, sprawdzone w praktyce rozwiazanie
˛
cz˛esto
pojawiajacych
˛
sie,
˛ powtarzalnych problemów projektowych.
Pokazuje powiazania
˛
i zależności pomiedzy
˛
klasami oraz
obiektami i ułatwia tworzenie, modyfikacje˛ oraz pielegnacj
˛
e˛
kodu źródłowego. Jest opisem rozwiazania,
˛
a nie jego
implementacja.
˛ Wzorce projektowe stosowane sa˛ w projektach
wykorzystujacych
˛
programowanie obiektowe.
Wprowadzenie
GRASP
Stosowanie zasad
5.4
G.R.A.S.P.
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
GRASP
General Responsibility Assignment Software Patterns (or
Principles)
1
2
Controller
Creator
3
High Cohesion
4
Indirection
5
Information Expert
6
Low Coupling
7
Polymorphism
8
Protected Variations
9
Pure Fabrication
Wprowadzenie
GRASP
Stosowanie zasad
5.5
G.R.A.S.P.
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
GRASP
Ogólne zasady przydzielania odpowiedzialności w
oprogramowaniu.
1
Kontroler
2
Twórca
3
Wysoka spójność
4
Pośrednictwo
5
Expert
6
Mało powiaza
˛ ń
7
Polimorfizm
8
Chroniona zmienność
9
Czyste wytwarzanie
Wprowadzenie
GRASP
Stosowanie zasad
Nazwy nie sa˛ najważniejsze: najważniejszy jest sens tych
zasad.
5.6
1. Controller
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Kontroler
Problem który obiekt (za interfejsem użytkownika)
powinien obsłużyć (przejać)
˛ operacje˛ (np.:
zewnetrzn
˛
a)
˛ systemu?
Rozwiazanie
˛
Powinna to być klasa, która:
opisuje system jako całość reprezentuje
główny obiekt lub urzadzenie
˛
na którym
system działa albo
reprezentuje przypadek użycia, w którym
wystepuje
˛
dana operacja
Wprowadzenie
GRASP
Stosowanie zasad
Opis podstawowa zasada dotyczaca
˛ oddzielenia
interfejsu od logiki aplikacji. Jest realizowana w
wielu wzorcach min.: Model-Widok-Kontroler
5.7
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
2. Creator
Twórca
Problem która klasa ma być odpowiedzialna za tworzenie
obiektów klasy A?
Rozwiazanie
˛
Klasa B jest odpowiedzialna za tworzenie A, gdy:
klasa B komponuje lub agreguje (”ma”)
obiekty klasy A
B zapisuje/rejestruje/nadzoruje instancje
klasy A
B współpracuje (blisko!) z A
B ma dane potrzebne do inicjalizacji A
(patrz: Ekspert)
Wprowadzenie
GRASP
Stosowanie zasad
Opis praktycznie każdy program obiektowy musi
tworzyć obiekty; właściwe zorganizowanie i
przypisanie które obiekty tworza˛ jakie inne
obiekty pozwala znaczaco
˛ zredukować ilość
powiaza
˛ ń miedzy
˛
klasami.
5.8
3. High Cohesion
Wysoka spójność
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Problem jak w praktyce zachować klase˛ skupiona˛ na
jednej odpowiedzialności, z przejrzysta˛
implementacja,
˛ zwiekszyć
˛
szanse ponownego
użycia?
Rozwiazanie
˛
gdy masz wybór, przypisuj odpowiedzialność tak,
by klasa była skupiona na jednym zadaniu
Opis Złamanie tej zasady to anty-wzorzec projektowy
"Blob": ma miejsce wtedy, gdy w programie
istnieje wiele klas, ale bardzo niewiele z nich (lub
jedna) ma dominujace
˛ znaczenie i zawiera sie˛ w
niej prawie cała istotna funkcjonalność. Takie
klasy nazywamy cz˛esto (negatywnie)
super-klasa, klasa-bóstwo, boss-klasa etc. W
szczególności NIGDY nie należy mieszać w
jednej klasie logiki aplikacji (co aplikacja
naprawde˛ robi) z dostepem
˛
do danych (skad
˛
bierze dane) – podobno za to idzie sie˛ do
programistycznego piekła ;)
Wprowadzenie
GRASP
Stosowanie zasad
5.9
4. Indirection
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Pośrednictwo
Problem jak unikać zależności od klas dostarczajacych
˛
funkcjonalność w specyficzny sposób? jak
przerywać zbyt mocne zależności miedzy
˛
klasami? jak korzystać z innych
klas/pakietów/usług bez dostosowywania sie˛ do
nich?
Rozwiazanie
˛
należy stworzyć nowy pośredni obiekt, służacy
˛
jako kanał komunikacji, tak by obiekty nie
kontaktowały sie˛ bezpośrednio
Opis aby obniżyć ilość zależności miedzy
˛
klasami
można umieścić miedzy
˛
nimi klase,
˛ przez która˛
bed
˛ a˛ sie˛ komunikować. Zmniejsza sie˛ też ogólna
ilość powiaza
˛ ń (zachowanie Low Coupling), bo
jedna klasa warstwy pośredniej może
odpowiadać paru klasom warstwy pierwotnej.
Przykładem sa˛ wzorce projektowe typu: Most,
Fasada, Adapter.
Wprowadzenie
GRASP
Stosowanie zasad
5.10
5. Information Expert
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Expert
Problem której klasie przypisać dana˛ odpowiedzialność
(zadanie)?
Rozwiazanie
˛
tej, która posiada najwiecej
˛
informacji
niezbednych
˛
do tego, by to zadanie wykonać
Opis Pochopne podejmowanie decyzji może
spowodować, że klasa aby wykonać zadanie
bedzie
˛
musiała przedostać sie˛ przez spory graf
obiektów, aby uzyskać odpowiednie informacje.
Stosowanie zasady Expert pozwala
oddelegować odpowiedzialność do podmiotu,
który na wstepie
˛
jest najlepiej przygotowany do
jej podjecie
˛
(stad:
˛ Ekspert - w sensie ”najlepszy
spośród wszystkich kandydatów”).
Wprowadzenie
GRASP
Stosowanie zasad
5.11
6. Low Coupling
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Mało powiaza
˛ ń
Problem jak utrzymać obiekty w niezależności od siebie?
Rozwiazanie
˛
tak przypisuj odpowiedzialności do obiektów, by
liczba powiaza
˛ ń była jak najmniejsza
Opis Klasa, która ma dużo powiaza
˛ ń, jest zależna od
wielu innych klas, co powoduje:
1
wiele lokalnych zmian spowodowanych
zmianami w klasach powiazanych;
˛
2
klasy trudniejsze do zrozumienia w izolacji;
3
zmniejszony „reuse” (możliwość ponownego
wykorzystania), ponieważ najcz˛eściej trzeba
jednocześnie wykorzystać cz˛eść klas
powiazanych;
˛
Klasa która ma za dużo powiaza
˛ ń
prawdopodobnie jest ”przeciażona”
˛
obowiazkami,
˛
co implikuje złamanie zasady High
Cohesion.
Wprowadzenie
GRASP
Stosowanie zasad
5.12
7. Polymorphism
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Polimorfizm
Problem jak przypisać odpowiedzialność, która może być
realizowana na kilka sposobów?
Rozwiazanie
˛
przypisz odpowiedzialność do hierarchii
obiektów wykorzystujac
˛ polimorfizm wbudowany
w jezyki
˛
obiektowe
Wprowadzenie
GRASP
Opis mechanizm polimorfizmu, pozwala
automatycznie decydować o tym ”co sie˛ stanie w
czasie działania programu” na podstawie
informacji ”jaki rodzaj obiektu został przekazany”
Stosowanie zasad
5.13
8. Protected Variations
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Chroniona zmienność
Problem jak projektować system, by umożliwić
wprowadzanie zmiany, tak by nie wymuszała ona
zmian na innych obiektach?
Rozwiazanie
˛
zidentyfikuj punkty przewidywanego
zróżnicowania/niestabilności i przypisz
odpowiedzialność do stabilnego interfejsu, a nie
konkretnych klas.
Opis chodzi o to, by wymiana klasy A na klase˛ B
oferujac
˛ a˛ podobna˛ funkcjonalność była jak
najprostsza. Ta fundamentalna zasada implikuje
enkapsulacje,
˛ polimorfizm, data-driven desig, a
nawet pliki konfiguracyjne!
Wprowadzenie
GRASP
Stosowanie zasad
5.14
9. Pure Fabrication
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Czyste wytwarzanie
Problem jaki obiekt powinien otrzymać odpowiedzialność,
gdy nie chcemy złamać High Cohesion i Low
Coupling, a proponowany Ekspert jest (z innych
przyczyn) nie do przyjecia?
˛
Rozwiazanie
˛
należy sztucznie ”wytworzyć” nowa˛ ”czysta”
˛
klase˛ (niezwiazan
˛
a˛ z problemem) i jej przypisać
te˛ odpowiedzialność
Opis Ta zasada cz˛esto jest używana jako ”złoty
środek” pozwalajacy
˛ utrzymać inne zasady, gdy
te stoja˛ w sprzeczności. Ponadto pomaga ona
uwolnić sie˛ od dziedziny problemu i rozwiazać
˛
go
”czysto informatycznie”. Przykłady: wzorce
Singleton, Factory.
Wprowadzenie
GRASP
Stosowanie zasad
5.15
Jak ważne sa˛ zasady?
Projektowanie
obiektowe: Zasady i
skad
˛ sie˛ biora˛
wzorce projektowe.
Pick your battles!
zasady nie sa˛ bezwzgledne
˛
trzeba dażyć
˛
do najszerszego ich spełniania
cz˛esto trzeba wybrać jedna˛ ponad druga˛
trzeba rozumieć kontekst w jakim sie˛ je stosuje
Wprowadzenie
GRASP
Jeżeli sie˛ pomyliłeś -> refaktoruj!
Stosowanie zasad
projektowanie to proces iteracyjny
różne diagramy pozwalaja˛ zobaczyć różne aspekty
systemu
5.16