5.1
Wykład 5
Projektowanie obiektowe: Zasady i
sk ˛
ad si ˛e bior ˛
a wzorce projektowe.
In˙zynieria oprogramowania
MIS-1-502-s MIO-1-505-s MIS-1-505-n
Listopad 2014
Kazimierz Michalik
Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
5.2
Agenda
1
2
3
5.3
Co to jest G.R.A.S.P.?
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”.
C. Larman: „Applying UML and Patterns”
„Metodyczne podej´scie do podstaw projektowania
obiektowego.”.
„Zasady/wzorce GRASP s ˛
a pomoc ˛
a w zrozumieniu istoty
projektowania obiektowego i stosowania go w metodyczny,
racjonalny i zrozumiały sposób".
5.4
Co to s ˛
a wzorce projektowe?
Wzorzec projektowy
uniwersalne, sprawdzone w praktyce rozwi ˛
azanie cz ˛esto
pojawiaj ˛
acych si ˛e, powtarzalnych problemów projektowych.
Pokazuje powi ˛
azania i zale˙zno´sci pomi ˛edzy klasami oraz
obiektami i ułatwia tworzenie, modyfikacj ˛e oraz piel ˛egnacj ˛e
kodu ´zródłowego. Jest opisem rozwi ˛
azania, a nie jego
implementacj ˛
a. Wzorce projektowe stosowane s ˛
a w projektach
wykorzystuj ˛
acych programowanie obiektowe.
5.5
G.R.A.S.P.
GRASP
General Responsibility Assignment Software Patterns (or
Principles)
1
Controller
2
Creator
3
High Cohesion
4
Indirection
5
Information Expert
6
Low Coupling
7
Polymorphism
8
Protected Variations
9
Pure Fabrication
5.6
G.R.A.S.P.
GRASP
Ogólne zasady przydzielania odpowiedzialno´sci w
oprogramowaniu.
1
Kontroler
2
Twórca
3
Wysoka spójno´s´c
4
Po´srednictwo
5
Expert
6
Mało powi ˛
aza ´n
7
Polimorfizm
8
Chroniona zmienno´s´c
9
Czyste wytwarzanie
Nazwy nie s ˛
a najwa˙zniejsze: najwa˙zniejszy jest sens tych
zasad.
5.7
1. Controller
Kontroler
Problem
który obiekt (za interfejsem u˙zytkownika)
powinien obsłu˙zy´c (przej ˛
a´c) operacj ˛e (np.:
zewn ˛etrzn ˛
a) systemu?
Rozwi ˛
azanie
Powinna to by´c klasa, która:
opisuje system jako cało´s´c reprezentuje
główny obiekt lub urz ˛
adzenie na którym
system działa albo
reprezentuje przypadek u˙zycia, w którym
wyst ˛epuje dana operacja
Opis
podstawowa zasada dotycz ˛
aca oddzielenia
interfejsu od logiki aplikacji. Jest realizowana w
wielu wzorcach min.: Model-Widok-Kontroler
5.8
2. Creator
Twórca
Problem
która klasa ma by´c odpowiedzialna za tworzenie
obiektów klasy A?
Rozwi ˛
azanie
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)
Opis
praktycznie ka˙zdy program obiektowy musi
tworzy´c obiekty; wła´sciwe zorganizowanie i
przypisanie które obiekty tworz ˛
a jakie inne
obiekty pozwala znacz ˛
aco zredukowa´c ilo´s´c
powi ˛
aza ´n mi ˛edzy klasami.
5.9
3. High Cohesion
Wysoka spójno ´s ´c
Problem
jak w praktyce zachowa´c klas ˛e skupion ˛
a na
jednej odpowiedzialno´sci, z przejrzyst ˛
a
implementacj ˛
a, zwi ˛ekszy´c szanse ponownego
u˙zycia?
Rozwi ˛
azanie
gdy masz wybór, przypisuj odpowiedzialno´s´c 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 dominuj ˛
ace znaczenie i zawiera si ˛e w
niej prawie cała istotna funkcjonalno´s´c. Takie
klasy nazywamy cz ˛esto (negatywnie)
super-klasa, klasa-bóstwo, boss-klasa etc. W
szczególno´sci NIGDY nie nale˙zy miesza´c w
jednej klasie logiki aplikacji (co aplikacja
naprawd ˛e robi) z dost ˛epem do danych (sk ˛
ad
bierze dane) – podobno za to idzie si ˛e do
programistycznego piekła ;)
5.10
4. Indirection
Po ´srednictwo
Problem
jak unika´c zale˙zno´sci od klas dostarczaj ˛
acych
funkcjonalno´s´c w specyficzny sposób? jak
przerywa´c zbyt mocne zale˙zno´sci mi ˛edzy
klasami? jak korzysta´c z innych
klas/pakietów/usług bez dostosowywania si ˛e do
nich?
Rozwi ˛
azanie
nale˙zy stworzy´c nowy po´sredni obiekt, słu˙z ˛
acy
jako kanał komunikacji, tak by obiekty nie
kontaktowały si ˛e bezpo´srednio
Opis
aby obni˙zy´c ilo´s´c zale˙zno´sci mi ˛edzy klasami
mo˙zna umie´sci´c mi ˛edzy nimi klas ˛e, przez któr ˛
a
b ˛ed ˛
a si ˛e komunikowa´c. Zmniejsza si ˛e te˙z ogólna
ilo´s´c powi ˛
aza ´n (zachowanie Low Coupling), bo
jedna klasa warstwy po´sredniej mo˙ze
odpowiada´c paru klasom warstwy pierwotnej.
Przykładem s ˛
a wzorce projektowe typu: Most,
Fasada, Adapter.
5.11
5. Information Expert
Expert
Problem
której klasie przypisa´c dan ˛
a odpowiedzialno´s´c
(zadanie)?
Rozwi ˛
azanie
tej, która posiada najwi ˛ecej informacji
niezb ˛ednych do tego, by to zadanie wykona´c
Opis
Pochopne podejmowanie decyzji mo˙ze
spowodowa´c, ˙ze klasa aby wykona´c zadanie
b ˛edzie musiała przedosta´c si ˛e przez spory graf
obiektów, aby uzyska´c odpowiednie informacje.
Stosowanie zasady Expert pozwala
oddelegowa´c odpowiedzialno´s´c do podmiotu,
który na wst ˛epie jest najlepiej przygotowany do
jej podj ˛ecie (st ˛
ad: Ekspert - w sensie ”najlepszy
spo´sród wszystkich kandydatów”).
5.12
6. Low Coupling
Mało powi ˛
aza ´
n
Problem
jak utrzyma´c obiekty w niezale˙zno´sci od siebie?
Rozwi ˛
azanie
tak przypisuj odpowiedzialno´sci do obiektów, by
liczba powi ˛
aza ´n była jak najmniejsza
Opis
Klasa, która ma du˙zo powi ˛
aza ´n, jest zale˙zna od
wielu innych klas, co powoduje:
1
wiele lokalnych zmian spowodowanych
zmianami w klasach powi ˛
azanych;
2
klasy trudniejsze do zrozumienia w izolacji;
3
zmniejszony „reuse” (mo˙zliwo´s´c ponownego
wykorzystania), poniewa˙z najcz ˛e´sciej trzeba
jednocze´snie wykorzysta´c cz ˛e´s´c klas
powi ˛
azanych;
Klasa która ma za du˙zo powi ˛
aza ´n
prawdopodobnie jest ”przeci ˛
a˙zona”
obowi ˛
azkami, co implikuje złamanie zasady High
Cohesion.
5.13
7. Polymorphism
Polimorfizm
Problem
jak przypisa´c odpowiedzialno´s´c, która mo˙ze by´c
realizowana na kilka sposobów?
Rozwi ˛
azanie
przypisz odpowiedzialno´s´c do hierarchii
obiektów wykorzystuj ˛
ac polimorfizm wbudowany
w j ˛ezyki obiektowe
Opis
mechanizm polimorfizmu, pozwala
automatycznie decydowa´c o tym ”co si ˛e stanie w
czasie działania programu” na podstawie
informacji ”jaki rodzaj obiektu został przekazany”
5.14
8. Protected Variations
Chroniona zmienno ´s ´c
Problem
jak projektowa´c system, by umo˙zliwi´c
wprowadzanie zmiany, tak by nie wymuszała ona
zmian na innych obiektach?
Rozwi ˛
azanie
zidentyfikuj punkty przewidywanego
zró˙znicowania/niestabilno´sci i przypisz
odpowiedzialno´s´c do stabilnego interfejsu, a nie
konkretnych klas.
Opis
chodzi o to, by wymiana klasy A na klas ˛e B
oferuj ˛
ac ˛
a podobn ˛
a funkcjonalno´s´c była jak
najprostsza. Ta fundamentalna zasada implikuje
enkapsulacj ˛e, polimorfizm, data-driven desig, a
nawet pliki konfiguracyjne!
5.15
9. Pure Fabrication
Czyste wytwarzanie
Problem
jaki obiekt powinien otrzyma´c odpowiedzialno´s´c,
gdy nie chcemy złama´c High Cohesion i Low
Coupling, a proponowany Ekspert jest (z innych
przyczyn) nie do przyj ˛ecia?
Rozwi ˛
azanie
nale˙zy sztucznie ”wytworzy´c” now ˛
a ”czyst ˛
a”
klas ˛e (niezwi ˛
azan ˛
a z problemem) i jej przypisa´c
t ˛e odpowiedzialno´s´c
Opis
Ta zasada cz ˛esto jest u˙zywana jako ”złoty
´srodek” pozwalaj ˛
acy utrzyma´c inne zasady, gdy
te stoj ˛
a w sprzeczno´sci. Ponadto pomaga ona
uwolni´c si ˛e od dziedziny problemu i rozwi ˛
aza´c go
”czysto informatycznie”. Przykłady: wzorce
Singleton, Factory.
5.16
Jak wa˙zne s ˛
a zasady?
Pick your battles!
zasady nie s ˛
a bezwzgl ˛edne
trzeba d ˛
a˙zy´c do najszerszego ich spełniania
cz ˛esto trzeba wybra´c jedn ˛
a ponad drug ˛
a
trzeba rozumie´c kontekst w jakim si ˛e je stosuje
Je˙zeli si ˛e pomyliłe ´s -> refaktoruj!
projektowanie to proces iteracyjny
ró˙zne diagramy pozwalaj ˛
a zobaczy´c ró˙zne aspekty
systemu
Document Outline
Wyszukiwarka
Podobne podstrony:
lecture slides
Lecture 04 05 06 C Primer New
Lecture 04 05 06 C Primer New
lecture slides 04
lecture slides Powerpoint Slides Week1 1 1 Homeostasis revised
lecture slides Powerpoint Slides Week1 1 4 Effective Solute & Water Transport revised
lecture slides Powerpoint Slides Week1 1 2 Homeostatic Regulation revised
lecture slides Powerpoint Slides Week1 1 3 Transporters, Pumps & Channels revised
lecture slides Powerpoint Slides Week1 1 6 Endocrine Assessment & Pathology revised v2
lecture slides Powerpoint Slides Week1 1 5 Endocrine General Concepts revised
lecture slides Powerpoint Slides Week1 1 0 Course Introduction revised
lecture slides 0105 EndoConcepts 2013 copyright
Feynman Lectures on Physics Volume 1 Chapter 05
lecture 05
więcej podobnych podstron