Transcript parsisiųsti skaidrę

Projektavimo šablonai
Design Patterns
1
Kas yra šablonas?
 “Kiekvienas šablonas aprašo problemą, kuri
pasikartoja iš naujo ir iš naujo mūsų aplinkoje
ir tuomet aprašo tos problemos sprendimo
esmę tokiu būdu, kad galima tą sprendimą
naudoti milijoną kartų, tačiau niekad to
nedarant du kartus tuo pačiu būdu.”
Christopher Alexander,
Architektas
2
Esminiai šablonų elementai (1)
 Šablono vardas – priemonė, aprašanti
projektavimo problemą, jos sprendimą ir
pasekmes keliais žodžiais.



Praturtina projektavimo žodyną.
Leidžia projektuoti didesniu abstrakcijos lygiu.
Palengvina mąstyma šablonais.
3
Esminiai šablonų elementai (2)
 Problema aprašo, kada naudoti šabloną.



Paaiškina problemą ir jos kontekstą.
Gali aprašyti specifines projektavimo
problemas, pvz. Kaip atvaizduoti algoritmus
kaip objektus.
Gali įtraukti sąrašą sąlygų, kurios turi būti
tenkinamos, kad būtų prasminga naudoti
šabloną.
4
Esminiai šablonų elementai (3)
 Sprendimas aprašo elementus, kurie
naudojami projektavime, jų tarpusavio ryšius,
atsakomybes ir bendradarbiavimus.


Sprendimas neaprašo konkretaus modelio ar
realizavimo, kadangi šablonas gali būti
pritaikytas daugelyje skirtingų situacijų.
Šablonas suteikia abstraktų projektavimo
problemos aprašą ir kaip bendras elementų
(klasių ir objektų) išdėstymas tą problemą
padeda išspręsti.
5
Esminiai šablonų elementai (4)
 Pasekmės – šablono taikymo rezultatai.


Nors pasekmės dažnai yra nutylimos, kuomet
aprašomi projektavimo sprendimai, jos yra
įpatingai svarbios, norint įvertinti projektavimo
altarenatyvas ir suprasti šablono taikymo
kainą bei privalumus.
Kadangi pakartotinis panaudojimas yra
svarbus faktorius OOD, šablono panaudojimo
pasekmės įtraukia jo įtaką sistemos
lankstumui ir praplečiamumui.
6
Šablonas:
 Bendraujančių objektų ir klasių aprašas, kuris yra
pritaikytas bendrai projektavimo problemai
konkrečiame kontekste.
 Projektavimo šablonas įvardina, abstrahuoja ir
identifikuoja esminius bendrinės projektavimo
struktūros aspektus, dėl kurių naudinga kurti
pakartotinio panaudojimo OO modelį.
 Taip pat identifikuoja dalyvaujančias klases, jų
atvejus, roles ir bendradarbiavimus bei atsakomybių
pasiskirstymą.
7
Šablonų klasifikacija
 Klasifikuojami pagal du kriterijus:

Paskirtis – atspindi tai, ką šablonas daro:




Kūrimo (Creational);
Struktūros (Structural);
Elgsenos (Behavioral).
Sritis – parodo ar šablonas pirmiausiai
taikomas klasėms ar objektams.
8
Šablonų klasifikacija
9
Kūrimo šablonai (1)
 Kūrimo šablonai susiję su objektų kūrimu.



Struktūriniai klasių šablonai atideda dalį
objekto kūrimo į subklases, o struktūriniai
objektų šablonai – kitam objektui.
Sistema tampa nepriklausoma nuo to, kaip jos
objektai yra kuriami, komponuojami ir
atvaizduojami.
Objektų kūrimo mechanizmas, kuriantis
objektus, tinkamu situacijai būdu.
10
Kūrimo šablonai (2)
 Lankstumas kuriant objektus:





Kas yra kuriama;
Kas kuria;
Kaip yra kuriama;
Kada kuriama;
Kuriama dinamiškai (run-time) ar statiškai
(compile-time)).
11
Struktūriniai šablonai
 Struktūriniai šablonai susiję su klasių ar
objektų struktūra.




Struktūriniai klasių šablonai naudoja
paveldėjimą klasių sudarymui, objektų
šablonai aprašo būdus, kaip surinkti objektą.
Parodo, kaip ‘sulipdyti’ skirtingus sistemos
gabalus lanksčiu ir praplečiamu būdu.
Klasių ir objektų sujungimui į didesnes
struktūras šablonai naudoja kompoziciją.
Palengvina projektavimą, parodant paprastą
būdą, kaip realizuoti ryšius tarp esybių.
12
Elgsenos šablonai
 Elgsenos šablonai charakterizuoja būdus, kuriais
klasės ar objektai sąveikauja ir dalinasi
atsakomybe.


Elgsenos klasių šablonai naudoja paveldėjimą
algoritmų ir vykdymo sekos aprašymui, objektų
šablonai aprašo, kaip grupė objektų
bendradarbiauja, kad atliktų užduoti, neįveikiamą
vienam objektui.
 Atsakomybės tarp objektų yra priskiriamos per
paveldėjimą arba kompoziciją.
Tarp bendraujančių objektų turi būti “loose coupling”
13
Šablonai pagal taikymo sritį
 Parodo ar šablonas pirmiausiai taikomas
klasėms ar objektams



Klasių šablonai susiję su ryšiais tarp klasių ir
jų subklasių.
Šie ryšiai nustatomi per paveldėjimą, taigi yra
statiniai (vykdomi kompiliavimo metu).
Objektų šablonai susiję su ryšiais tarp objektų,
kurie gali būti keičiami vykdymo metu ir yra
labiau dinaminiai.
14
Ryšiai tarp šablonų
15
Ryšiai tarp šablonų
16
Projektavimas pakeičiamumui (1)
 Objekto sukūrimas tiksliai nurodant klasę.


Klasės vardo nurodymas susieja su konkrečia
realizacija, o ne su konkrečiu interfeisu ir
pakeitimai ateityje gali komplikuotis.
Kad to išvengti, objektus reikėtų kurti
netiesiogiai
Šablonai: Abstract Factory, Factory Method, Prototype.
17
Projektavimas pakeičiamumui (2)
 Priklausomybė nuo specifinių operacijų.


Nurodant konkrečią operaciją įsipareigojama
vienam būdui, kad patenkinti užklausą.
Vengiant ‘hard-coded’ užklausų, galima
lengviau atlikti pakeitimus užklausų
patenkinimui kompiliavimo ir vykdymo metu
Šablonai: Chain of Responsibility, Command.
18
Projektavimas pakeičiamumui (3)
 Priklausomybė nuo aparatūrinės ir
programinės įragos platformos.


Programinę įrangą, kuri priklauso nuo
konkrečios platformos, sunku pernešti į kitas
platformas.
Svarbu projektuoti sistemas, mažinant
priklausomybę nuo platformos.
Šablonai: Abstract Factory, Bridge.
19
Projektavimas pakeičiamumui (4)
 Priklausomybė nuo objekto atvaizdavimo ar
realizavimo.


Klientus, kurie žino, kaip objektas yra
atvaizduotas, saugomas ar realizuotas, gali
tekti keisti, kuomet bus pakeistas objektas.
Paslepiant šia informacija nuo kliento, galima
išvengti pakopinių pakeitimų.
Šablonai: Abstract Factory, Bridge, Memento, Proxy.
20
Projektavimas pakeičiamumui (5)
 Priklausomybė nuo algoritmų.



Algortimai yra dažnai praplečiami,
optimizuojami ar pakeičiami kurimo metu.
Objektai, priklausantys nuo algortimo, taip pat
turės keistis.
Algoritmai, kurie linkę keistis, turėtų būti
izoliuojami.
Šablonai: Builder, Iterator, Strategy, Template Method, Visitor.
21
Projektavimas pakeičiamumui (6)
 Tight coupling.


Klases, kurios yra tvirtai susietos, yra sunku
naudoti atskirai.
Tokiose monolitinėse sistemose yra sunku
pakeisti ar pašalinti klasę, nesuprantant ar
nekeičičiant daugelio kitu klasių.
Šablonai: Abstract Factory, Bridge, Chain of Responsibility,
Command, Facade, Mediator, Observer.
22
Projektavimas pakeičiamumui (7)
 Negalėjimas patogiai keisti klases.

Kartais gali prireikti keisti klases, kurios negali
būti modifikuojamos patogiai:


Reikia kodo, kurio neturime (komercinės klasių
bibliotekos);
Pakeitimai reikalaus pakeisti daug egzistuojančių
subklasių.
Šablonai: Adapter, Decorator, Visitor.
23
Singleton (creational pattern)
 Užtikrina, kad klasė turėtų tik vieną
egzempliorių ir suteikia globalų priėjimo prie
jo tašką.
 Klasė pati yra atsakinga už vienintelio objekto
prižiūrėjimą.
 Klasė užtikrina, kad nebus sukurta kitų
objektų.
24
Kada naudoti?
 Kuomet turi būti tik vienas klasės objektas ir
jis turi būti prieinamas kilentams per gerai
žinoma priėjimo tašką.
 Kuomet vienintelis objektas turi būti
praplečiamas subklasėmis ir klientai turi galėti
naudoti praplėstą objektą nekeičiant savo
kodo.
25
Singleton šablonas. Pagrindimas


Kiekviena klasė, kuriai reikia prieiti prie failo
(Clients), sukuria ir sunaikina objektą (FileObj).
Gali kilti duomenų vientisumo problemų, kai kurios
sistemos to neleidžia ir t.t.
26
Singleton šablonas. Pagrindimas
 Galima sukurti globalų kintamajį.
 Negalima garantuoti, kad visi programuotojai
prisimins ir naudos šią logiką.
 Kyla klausimas – kaip sustabdyti naujų
objektų kūrimą.
27
Singleton šablonas. Pagrindimas
28
Singleton šablonas. Realizacija
 Reikia sustabdyti klasės FileObj objektų kųrima
normaliu budu.
 Java – klasę aprašome kaip Static.
 C++ - klasę aprašom kaip Protected.
 Metodas, naudojamas priėjimui prie objekto (public
getInstance()) – užtikrina, kad esamu momentu
egzistuota tik vienas klasės objektas:
 Jei objektas nesukurtas – sukuriamas naujas;
 Jei objektas egzistuoja – gražinama nuoroda i jį.
 Šį metodą kvies kiekvienas klientas, kuris norės
prieiti prie objekto.
29
Singleton struktūra
Static Member
Private
konstruktorius
Static public metodas
Grąžina nuorodą į static
member
30
Singleton sekų diagrama
31
Singleton kodas
Panaudojimas:
32
Panaudojimo pavyzdžiai
 Logger Classes:
Paprastai realizuojamos kaip singleton‘ai ir suteikia globalų
prisijungimo tašką visiems programos komponentams. Nebereikia
kurti naujo objekto kiekviną kartą, kai įvyksta prisijungimo operacija.
 Configuration Classes:
 Naudojamas projektuojant klases, suteikiančias konfigūracijos
nustatymus taikomosioms programoms.
 Accesing resources in shared mode:

Gali būti naudojamas projektuojant programas, kurios dirba su nuosekliuoju
prievadu (serial port).
Factories implemented as Singletons:
 Projektuojam programą su Fabriku, kad jis sugeneruotų naujus objektus
(Account, Customer, Site, Address) su identifikatoriais (ID) ‘multithreading’
aplinkoje. Jei fabrikas iškviečiamas per du skirtingus thread’us, gali buti
sukurti persidengiantys ID skirtingiems objektams.


33
Singleton kodas. Multi-Thread
34
Pavyzdys
35
Privalumai
 Galima naudoti visada, kai tik reikia
kontroliuoti objektų kūrimą:

Objektas negali būti tiesiogiai sukurtas iš
klasės, o tik per getInstance() metodą.
 Užkerta kelią kitiems objektams kurti savo
Singleton objekto kopijas ir užtikrina, kad visi
objektai prieina prie vieno objekto.
 Kadangi klasė valdo kūrimo procesą, galima
joje tą procesą keisti.
36
Singleton kodas
37