Tehnici de proiectare software - Tipografia

More documents

Recommendations

Info

• Utilizare Şablonul Chain Of Responsibility se foloseşte când: - există un grup de obiecte în sistem care pot răspunde la acelaşi tip de mesaj - mesajele trebuie folosite de unul din obiectele din sistem - mesajele folosesc modelul "folosire sau trimitere mai departe", adică unele mesaje pot fi utilizate la nivelul unde au fost recepŃionate sau produse, în timp ce altele trebuie trimise mai departe către alte obiecte ■ Descriere Când unele acŃiuni au loc într-un sistem orientat pe obiecte, acestea sunt de regulă reprezentate printr-un eveniment sau mesaj. Un astfel de mesaj poate lua forma unei metode care e apelată sau poate fi un obiect al sistemului. Mesajul este apoi direcŃionat către un alt obiect care poate răspunde sau utiliza mesajul. In cele mai simple cazuri, acelaşi obiect care produce mesajul, răspunde la el. De exemplu, un câmp unde se introduce un text poate produce un eveniment ca răspuns la acŃiunea utilizatorului - cum ar fi tastarea. In cele mai complexe cazuri, răspunsul la mesaje implică mai multe lucruri. Un mesaj care cere o modificare în apariŃia interfeŃei grafice cu utilizatorul poate fi analizat la mai multe niveluri. Dacă cererea este aceea de a se modifica aliniamentul textului dintr-un câmp. componenta însăşi poate răspunde. însă o cerere de schimbarea a aliniamentului întregului text va fi probabil direcŃionată către nişte obiecte de nivel înalt. Şablonul Chain Of Responsibility reprezintă un lanŃ pentru mesaje. Dacă un obiect nu poate răspunde la un mesaj primit, el trimite mesajul mai departe către alt obiect. în mod frecvent, şablonul Chain Of Responsibility este implementat după un model părinte-fiu. Astfel, mesajele ce nu pot fi utilizate de către fiu sunt trimise părintelui, şi aşa mai departe dacă este cazul, până când este întâlnit un obiect ce poate răspunde mesajului. Şablonul Chain Of Responsibility este potrivit pentru o varietate mare de activităŃi efectuate cu o interfaŃă grafică cu utilizatorul orientată pe obiecte. FuncŃiile de ajutor, structura componentelor, formatare şi poziŃionare cuprinse în interfaŃa grafica pot folosi acest şablon. ■ Implementare Diagrama de clase a şablonului Chain Of Responsability este următoarea: Client interface Handler void handleMessage () ConcreteHandler -Handler handler +void handleMessageQ +void handlerMethod() if(can handle) handlerMethodQ else succesor.handleMessage() 21
Pentru implementarea şablonului Chain Of Responsibility este nevoie de: - Handler - interfaŃa ce defineşte metoda folosită pentru trimiterea mesajului către următorul Handler. Acest mesaj reprezintă de regulă doar apelarea metodei, dar în cazul în care o cantitate mai mare de date trebuie încapsulată, poate fi trimis de asemenea şi un obiect - ConcreteHandler - clasa care implemetează interfaŃa Handler. Ea păstrează o referinŃă către următoarea instanŃă către Handler. Această referinŃă este fie conŃinută în constructorul clasei sau într-o metodă proprie. Implementarea metodei handleMessage poate determina cum să se folosească metoda, cum să se apeleze metoda handleMethod şi cum să se trimită mesajul către următorul Handler ■ Beneficii şi inconveniente Şablonul Chain Of Responsibility oferă flexibilitate mare în procesarea evenimentelor pentru o aplicaŃie, deoarece oferă posibilitatea de management a unor evenimente complexe prin împărŃirea responsabilităŃilor între un număr de elemente simple. Permite ca un set de clase să se comporte ca un întreg, astfel ca evenimentele produse într-o clasă pot fi trimise către celelalte clase. Insă flexibilitatea acestui şablon are un preŃ, el devenind dificil de dezvoltat şi testat. Pe măsură ce lanŃul devine mai complex, trebuie monitorizată cu atenŃie propagarea evenimentelor. Eşecul în trimiterea evenimentelor poate avea ca rezultat pierderea mesajelor, acestea rămânând fără răspuns. Daca mai multe mesaje sunt produse într-o perioadă scurtă de timp, ele fiind apoi trimise de mai multe ori până sunt utilizate, are loc încetinirea sistemului. • Variante ale şablonului Exista mai multe căi de adaptare a şablonului Chain Of Responsibility încât el sa răspundă cerinŃelor diverselor aplicaŃii. Cele două strategii luate în considerare sunt cele de utilizare - handling - şi cele de trimitere mai departe - forwarding - a mesajelor. La cele de utilizare important este modul în care a fost implementat handler-ul. Printre variantele acestor strategii se număra: - Default Handler - unele implementări pornesc de la un handler de bază. Acesta este de regulă folosit atunci când nu este definită explicit o clasă care să trimită mesajul mai departe. Este de mare ajutor în evitarea pierderilor de mesaje - Handle And Extend - în cazul acestei variante, utilizarea evenimentelor implică adăugarea lor într-un comportament de bază pe măsura ce ele sunt propagate de-a lungul lanŃului. Acesta este de ajutor în activităŃile de logare - Dynamic Handler - unele implementări ale şablonului Chain Of Responsibility permit ca structura de trimitere a mesajelor să fie modificată la rulare. Prin definirea unei metode de setare pentru fiecare clasă a lanŃului, se poate defini şi modifica lanŃul pe măsură ce este folosit în cadrul aplicaŃiei Strategiile de trimitere mai departe a mesajelor definesc modalităŃi de utilizare sau trimitere a mesajelor produse de o componentă:
Page 1 and 2: TEHNICI DE PROIECTARE SOFTWARE Proi
Page 3 and 4: I. Introducere 1.1. De ce şabloane
Page 5 and 6: II. Şabloane creaŃionale Aceste
Page 7 and 8: Implementare Diagrama de clase a ş
Page 9 and 10: .'.tor obiecte ConcreteFactory. rez
Page 11 and 12: Daca însă responsabilitatea creă
Page 13 and 14: . ■ - - 2 class /ippoir tmGnt Bui
Page 15 and 16: - se doreşte ca o subclasa şi nu
Page 17 and 18: î n t e r r ci L.. e o h d o e \ p
Page 19 and 20: Pentru implementarea şablonului Pr
Page 21 and 22: • Utilizare Şablonul Singleton s
Page 23: III. Şabloane comportamentale Şab
Page 27 and 28: class PurcnaseKequest { privare iri
Page 29 and 30: Pentru implementarea şablonului Co
Page 31 and 32: III.3. Interpreter • ProprietăŃ
Page 33 and 34: Crearea arborelui de sintaxă abstr
Page 35 and 36: ■ Descriere Şablonul Iterator pe
Page 37 and 38: - Visitor - atunci când şablonul
Page 39 and 40: • Descriere Pe măsură ce comuni
Page 41 and 42: Exemplu Având o interfaŃă grafic
Page 43 and 44: Pentru implementarea şablonului Me
Page 45 and 46: obiect de tip State. Acest obiect e
Page 47 and 48: TranziŃiile se stochează într-un
Page 49 and 50: De fiecare dată când se vrea intr
Page 51 and 52: - Flyweight - câteodată obiectele
Page 53 and 54: Totuşi, cum se poate calcula timpu
Page 55 and 56: ■ Beneficii şi inconveniente Dat
Page 57 and 58: 111.10. Template Method • Proprie
Page 59 and 60: • Beneficii şi inconveniente Pri
Page 61 and 62: IV. Şabloane structurale Şabloane
Page 63 and 64: - ConcreteAdapter - clasa care impl
Page 65 and 66: IV.2. Bridge • Cunoscut şi ca Ha
Page 67 and 68: • Beneficii şi inconveniente Şa
Page 69 and 70: ■ Introducere Se doreşte modific
Page 71 and 72: Beneficii şi inconveniente Şablon
Page 73 and 74: Introducere Şablonul Composite des
Page 75 and 76:
Trebuie asigurată tratarea în mod
Page 77 and 78:
Separând un sistem într-un număr
Page 79 and 80:
interiace Private exLencis Genera]
Page 81 and 82:
Pentru implementarea şablonului Fl
Page 83 and 84:
• Introducere O aplicaŃie Java p
Page 85 and 86:
Un alt mare avantaj este că acest
Page 87 and 88:
SoluŃia este un obiect placeholder
Page 89 and 90:
la.ss Jmage extends Graphic{ public
Page 91:
Bibliografie 1. Stelting Stephen, M
show all

Tehnici de proiectare software - Tipografia

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?