1 / 68

Vzorci načrtovanja (Design patterns)

Vzorci načrtovanja (Design patterns). O čem bomo govorili. Kaj so načrtovalski vzorci ( design pattern ) ? Zakaj jih potrebujemo ? Kako jih lahko uporabimo ? Zgled : “ factory pattern ”. Frameworks. Patterns. UML Diagrams. Use case description. Kaj so vzorci ?.

gur
Download Presentation

Vzorci načrtovanja (Design patterns)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Vzorci načrtovanja (Design patterns)

  2. O čem bomo govorili • Kaj so načrtovalski vzorci (design pattern)? • Zakaj jih potrebujemo? • Kako jih lahko uporabimo? • Zgled: “factory pattern” Frameworks Patterns UML Diagrams Use case description

  3. Kaj so vzorci? • Vzorci opisujejo pogoste probleme, opisujejo tudi bistvo rešitve. Na ta način lahko rešitev ponovno uporabimo na več načinov. • Še ena definicija : “opisi objektov in razredov, ki komunicirajo in ki so prilagojeni reševanju splošnega načrtovalskega problema v nekem posebnem kontekstu”.

  4. Vzorci v realnem življenju • Vzemimo primer, pojem “vrat” je zelo splošen: Povezuje dve stvari, Lahko jih odpremo ali zapremo. Hišna vrata in vodna pipa so “vrata”. Imajo nekaj skupnega: • Dve strani • Nekaj (pretok), kar lahko teče. • Hitrost pretoka. • Če razumemo te, skupne stvari, lahko gradimo boljša “vrata”

  5. Zakaj jih rabimo v programskem inženirstvu? • Sporočajo probleme in njihove rešitve, do katerih so skozi vrsto projektov prišli izkušeni razvijalci. • Zapisani so na abstrakten način in jih zato lahko uporabimo v različnih kontekstih

  6. Interna uporaba v aplikacijah • Prednost je v zmožnostih vzdrževanja in razširjanja. • Interna ponovna uporaba pomeni za dano aplikacijo zmanjšanje načrtovanja in implementacije • Načrtovalski vzorci, ki zmanjšujejo sklapljanje in povečujejo sodelovanje, lahko povečujejo interno ponovno uporabljivost.

  7. Košarice orodij -Toolkits • To so knjižnice vnaprej definiranih, med seboj povezanih in ponovno uporabljivih razredov. • Aplikacije imajo take “košarice” vgrajene (na primer C++ I/O stream library). • Aplikaciji ne vsiljujejo načrta, odvračajo pa programerje od ponovnega kodiranja funkcionalnosti. • Njihov razvoj je težji od razvoja aplikacij, saj morajo predvideti delovanje v različnih aplikacijah.

  8. Ogrodja (frameworks) • Framework: Skupina sodelujočih razredov, ki omogočajo ponovno uporabljiv razvoj za določeno vrsto programov. • Ogrodja so prilagojena posamezni aplikaciji tako, da iz abstraktnih razredov tvorimo aplikaciji specifične podrazrede. • Ogrodja diktirajo arhitekturo aplikacije • Bolj poudarjajo ponovno uporabo razvoja in ne ponovno uporabo kode. • Implementirati jih je zelo težko.

  9. Razlika med vzorci in ogrodji • Načrtovalski vzorci (design patterns) so bolj abstraktni od ogrodij (frameworks) • Načrtovalski vzorci so manjši gradniki. • Načrtovalski vzorci so manj specializirani od ogrodij.

  10. Inverzija nadzora • Ponovna uporaba (v ogrodjih) povzroči inverzijo nadzora med aplikacijo in programsko opremo, na kateri ta temelji. • Pri košarici (toolkit) pišemo kodo aplikacije in kličemo košarico. • Z ogrodjem pa ponovno uporabimo glavno telo in pišemo kodo, ki je klicana iz tega telesa.

  11. Mislimo na to... • Kdaj bomo uporabili aplikacijo, kdaj košarico (toolkit) in kdaj ogrodje (framework)? • Če moramo v kratkem razviti manjšo spletno lokacijo in smo neizkušeni, kateri pristop je boljši?

  12. Primer: vzorecObserver • Primer obdelave besedil • Kaj se dogaja: • Kontrolerobvesti model, da naj vključi vtipkano besedilo • Model opozori vse poglede (views) o spremembi v modelu • Pogledi se osvežijo • Med osvežitvijo vsak pogled vpraša model, kakšno je trenutno besedilo.

  13. Vzorec Observer (2) • Kontekst • Nek objekt (“subjekt”) je izvor dogodkov (“moji podatki so se spremenili”) • Eden ali več objektov -opazovalcev (“observers”) želi vedeti, kdaj pride do nekega dogodka. • Rešitev • Definiramo vmesnik za tip observer. Razredi opazovalca morajo implementirati ta tip vmesnika • Subjekt vzdržuje kolekcijo objektov observer • Razred subjekta nudi metode za navezovanje opazovalcev • Ko pride do dogodka, subjekt opozori vse opazovalce

  14. Primer: vzorec Abstract factory • Nudi vmesnik za tvorbo družin povezanih oziroma odvisnih objektov,ne da bi pri tem specificirali njihove konkretne razrede • Motivacija: Zgledna “košarica orodij” za vmesnike, ki podpira različne standarde “look and feel”. • Drugi primeri: Web Services Description Language (WSDL) in OACS contract services

  15. Nekateri arhitekturni vzorci • Facade: Dinamična informacija na spletni strani je pogosto sestavljena iz množice vsebinskih objektov. • Templated page. Definira eno šablonsko stran, skozi katero morajo iti vse izhodne strani, preden so servisirane. • Thin Client. Vsa poslovna logika se izvaja na strežniku. • Thick web client. Tenek odjemalec je razširjen s skripti na strani odjemalca in prilagojenimi objekti (na primer appleti in Flash)

  16. Zakaj vzorci? • Učenje razvoja programov je težavno • Jeziki in ogrodja so zelo kompleksni • Imeti moramo boljši način komunikacije • Vzorci in jezik vzorcev (“pattern languages”) dajejo delni odgovor

  17. Kaj je načrtovalski vzorec? • Rešitev načrtovalskega problema, ki pogosto nastopa • Pomaga tvorbo fleksibilnega in ponovno uporabljivega načrta • Ima širši pomen od posameznega razreda ali algoritma • Opisuje okoliščine, pri katerih lahko vzorec uporabimo • Opisuje posledice in “ceno” (trade-offs) uporabe vzorca v sklopu nekega večjega načrtovanja • Je jezikovno neodvisen

  18. Od kod prihajajo vzorci • Vzorci prihajajo iz arhitekture • A Pattern Language [Alexander77] • Jezik vzorcev (Pattern Language) opisuje • Pogosti arhitekturni motivi • Kako z vsem skupaj ustvariti bivalno okolje

  19. Arhitekturni in načrtovalski vzorci • Arhitekturni vzorcinaslavljajo probleme • Porazdeljene funkcionalnosti in razdelitve sistema • Protokolov in vmesnikov • Skalabilnosti, zanesljivosti, varnosti • Delovanja in vpliva “porazdeljenega sistema” • Načrtovalski vzorcinaslavljajo probleme • Vzdrževalnosti, ponovne uporabljivosti kode, ogrodij (frameworks) • Abstrakcije in skrivanja algoritmov • Vpliva “objektno usmerjenega jezika”

  20. Zakaj uporabiti načrtovalske vzorce? • Preskušene rešitve pogostih OO problemov • Prenos izkušenj začetnikom • Skupen slovar načrtovalcev • Dokumantacija za obstoječa ogrodja • Ko to osvojimo, postanejo dobre tehnike načrtovanja naravne • Pogosto jih kombiniramo in ustvarjamo bolj sofisticirane načrte

  21. Katere probleme rešujemo z načrtovalskimi vzorci? • Dobri načrti se sprememb ne bojijo • Uporabljene tehnologije se spreminjajo • Poslovni cilji se spreminjajo • Pričakovanja uporabnikov se spreminjajo • OOP nudi orodja za spopad s spremembami: • Enkapsulacija • Dedovanje • Polimorfizem • Imeti orodja = dobro. Jih dobro uporabljati = boljše.

  22. Primer problema • In the beginning, you get the following requirement: The regional sales entry system must send data, in batches, to the accounting package (Microsoft Great Plains Accounts Receivable). • You create the OrderCollector class.

  23. In sedaj sprememba zahtevkov • Good news: our departmental application is being picked up by the manufacturing division in Florida. • Bad news: they use Solomon for their accounting package. Fix the code to use Solomon as well as Microsoft Great Plains. • The interaction is quite different. You have to change the code that calls the accounting interface.

  24. Novi diagram

  25. Problem z rešitvijo • The code to call the Microsoft Great Plains solution is similar to the code that calls the Solomon solution. • Business rules specific to the task of “send something to accounting” are mixed in with business rules for “send data to the specific package.” • Therefore: if another accounting package comes in, say Oracle, you’d have to do it again. • The interfaces are fairly different… inheritance doesn’t appear to help.

  26. Uporabimo vzorec Adapter • Adapter “pretvori vmesnik razreda v nek drug vmesnik, ki ga odemalec pričakuje.” • V nasednjem primeru uporabljamo variacijo vzorca Adaptee,ki mu pravimo “pluggable adapter using abstract operations” • Vzorec izgleda tako:

  27. Boljša OO rešitev

  28. Boljša zaradi ... • Poslovna pravila so ločenaod tehničnih pravil. Zato jih lažje beremo in preskušamo. • Poslovna pravila implementiramo enkrat in samo enkrat. Zato jih lažje najdemo in posodabljamo. • Če dodamo nov sistem obračunavanja, moramo sprogramirati le nov adapter. Poslovna koda že obstaja in jo (običajno) lahko ponovno uporabimo.

  29. In kaj smo s tem pridobili? To bi vendar lahko naredil s programsko šablono (code template)! To sem že prej sam, delal! Zakaj bi temu rekli vzorec? Moč načrtovalskih vzorcev ni le v šablonah in delčkih ponovno uporabljive kode… uvajajo nov način razmišljanja o objektih. Vzorci so primeri, ki nas vodijo v ta preskok.

  30. Nekaj vprašanj • Ali so objekti le “podatki z metodami?” • Ali pomeni enkapsulacija isto kot skrivanje podatkov? • Ali dedovanje najbolje uporabljamo za tvorbo “specializiranih” verzij razreda?

  31. Drug način razmišljanja • Enkapsulacija = skrivanje vsega… ne le podatkov • Objekti kot “realizirana množica odgovornosti” • Abstraktni razredi, ki definirajo “skupne” zmožnosti objekta, z dedovanjem, s katerim specificiramo variacije.

  32. Drug način programiranja • Usmerimo se v to, kaj naj bi objekti naredili, ne pa le, kako jih implementirati. • Razmislimo, kaj je v načrtu spremenljivega... nato pa to skrijmo. • Postavimo plasti med stvari, ki se spreminjajo neodvisno. • Načrtovalski vzorci = uporabljene najboljše izkušnje iz načrtovanja programov • Preskušene metode za skrivanje stvari, ne le podatkov. • “Commonality vs. Variability” je bistvo načrtovalskih vzorcev

  33. Kaj pridobimo z načrtovalskimi vzorci • Vzpostavimo besednjak • Ekipe lahko komunicirajo na višjem nivoju • Zaradi ponovne uporabe tehnične rešitve se lahko bolj usmerimo v poslovni problem • Dokumentacijo bomo lažje razumeli • Izboljšamo naše kodiranje • Lažje bo vzdrževanje: manj povezovanja, večja kohezija • Osvojili bomo pojme “commonality vs. variability” • Poveča se naša produktivnost • Zakaj bi spet izumljali kolo?

  34. Vzorci

  35. Trenutna uporaba vzorcev Razvijalci Katalog vzorcev (večinoma s primeri kode Izvorna koda

  36. Generiranje kode, temelječe na vzorcih • Dober vzorec naj bi imel najmanj tri znane dobre implementacije, kar kaže, da se ga da uporabiti na več načinov • Ta relacija ena na več vzpodbuja uporabo vzorcev za generiranje kode

  37. Strukturni vzorci (Structural Patterns) • Nek podsistem vsebuje • Objekt vmesnik (interface) • Množico objektov aplikacijske domene, ki modelirajo resnične entitete ali obstoječe sisteme • Enega ali več nadzornih objektov • Realizacija objekta vmesnik : Facade • Nudi vmesnik do podsistema • Vmesnik do obstoječega sistema: Adapter ali Bridge • Nudi vmesnik do obstoječega sistema

  38. VzorecFaçade • Facade nudi poenoten vmesnik do skupine razredov v podsistemu • Abstrahira bistvo podsistema in skrije podrobnosti implementacije in kompleksne povezave med komponentami • Primeri: vmesnik za povezovanje z več podatkovnimi bazami (JDBC) ali omrežnimi strežniki (sockets/RMI) in skrivanje podrobnosti povezovanja

  39. Vzorec Façade Za povezovanje s podatkovno bazo:

  40. Tvorba razredov Façade • Najprej naložimo gonilnik podatkovne baze try{Class.forName(driver);} //load the Bridge driver catch (Exception e) {System.out.println(e.getMessage());} • Se povežemo s podatkovno bazo try {con = DriverManager.getConnection(url); dma =con.getMetaData(); //get the meta data } catch (Exception e) {System.out.println(e.getMessage());} • Potrebujemo seznam imen tabel, z metodo getTabledobimo objekt ResultSet. • Seznam imen dobimo z iteracijo preko tega objekta

  41. Tvorba razredov Façade (nadaljevanje). public String[] getTableNames() { String[] tbnames = null; Vector tname = new Vector(); //add the table names to a Vector //since we don't know how many there are try { results = new resultSet(dma.getTables(catalog, null, "%", types)); } catch (Exception e) {System.out.println(e);} while (results.hasMoreElements()) tname.addElement(results.getColumnValue("TABLE_NAME")); //copy the table names into a String array tbnames = new String[tname.size()]; for (int i=0; i< tname.size(); i++) tbnames[i] = (String)tname.elementAt(i); return tbnames; }

  42. Adapter • Namen • Pretvorba vmesnika nekega razreda v drug vmesnik, kakršnega pričakujejo odjemalci • Znan tudi kot Wrapper • Motivacija • Potencialno ponovno uporabljiv razred nima ustreznega vmesnika, ki ga zahteva določeno področje uporabe • Uporabnost. Uporabimo, ko… • hočemo uporabiti razred, njegov vmesnik pa nam ne ustreza • hočemo narediti ponovno uporabljiv razred , ki sodeluje z nepredvidenimi razredi

  43. Adapter • Struktura • uporablja večkratno dedovanje (ali njegov ekvivalent) za prilagoditev enega vmesnika na drugega. • Udeleženci • Cilj (target), Odjemalec (Client), Prilagojenec (Adaptee), Prilagoditelj (Adapter) • To je predstavitev razreda adapter – imamo lahko tudi objekt adapter – uporabimo delegiranje namesto dedovanja

  44. Adapter – Primer kode • Pomislimo na urejevalnik, ki podpira like (shapes) in besedilo(text) • Text in Shape sta bila načrtovana neodvisno - vendar si želimo, da bi ju enako uporabljali • na primer. • Shape uporablja očrtan pravokotnik (Bounding Box), • Text pa uporablja izhodišče (origin), višino (height) in širino (width)

  45. Adapter – Primer kode (2) • Adapter za združevanje vmesnika uporablja dedovanje in implementacijo. • V našem primeru prihaja vmesnik od “Shape”, implementacija pa od “Text”. • TextShape se obnaša tako kot objekt Shape in kot objekt Text.

  46. Adapter - posledice • Class Adapter: • Prilagodi prilagojenca (adaptee) cilju tako, da posreduje konkretnemu razredu. Tako ne moremo prilagoditi razreda ali njegovih podrazredov • Adapter lahko prekrije določeno obnašanje prilagojenca • Uvede le en objekt in nobenih dodatnih kazalcev • Object Adapter: • Dopusti, da adapter sodeluje z več prilagojenci • Obnašanje prilagojencev težje prekrijemo

  47. VzorecBridge • Podoben vzorcu Adapter: uporabimo razred za pretvorbo enega vmesnika v drugega • Uporabljamo kot “up-front” v načrtovanju in tako omogočimo neodvisno spreminjanje abstrakcij in implementacij • Vzorce “Bridge” uporabljamo če v času analize ali načrtovanja še ne popolnoma poznamo celotne množice.

  48. VzorecProxy • Namen • Ponudi nadomestek za drug objekt. Ta nadomestek nadzoruje dostop do njega • Poznan tudi kot • Surrogate • Uporaba: • Za skrivanje kompleksnosti omreženega objekta • Pomoč pri nalaganju objekta s počasnim dostopom • Preverjanje dovoljenj za dostop do objekta in validacija njegove uporabe • So primeri, ko odjemalec ne more neposredno naslavljati nekega objekta, pa vseeno želi z njim interaktirati • Objekt “proxy” lahko deluje kot posrednik med odjemalcem in ciljnim objektom

  49. Tipi vzorcev Proxy • Remote Proxy • Lokalni predstavnik objekta, ki je v drugem naslovnem prostoru • Virtual Proxy • Dovoljuje tvorbo “na zahtevo” pomnilniško intenzivnega objekta. • Objekt bo tvorjen le, ko ga zares potrebujemo • Protection Proxy • Proxy nudi nadzor dostopa do resničnega objekta

  50. Vzorec Proxy : primer • Pomislimo na program, ki mora naložiti in prikazati sliko • Ob zagonu programa, imamo indikacijo slike, ki naj bo prikazana • To je pomembno za oblikovalnike besedil in brkljalnike, ki z besedilom obkrožijo sliko, še preden je ta naložena • Image proxy zabeleži sliko, ki se nalaga

More Related