abloane de proiectare

Design Patterns

Ce este un ablon de proiectare?

Definiie: Fiecare ablon reprezint o regul care exprim o relaie dintre un context, o problem care apare mereu n domeniul nostru de activitate i o soluie, utilizarea creia se permite de nenumrate ori n contexte diferite ( Christopher Alexander, 1979 ).
Un ablon reprezint o soluie comun a unei probleme ntr-un anumit context.

Clasificarea abloanelor (I)

Dup scop:
abloane creaionale (creational patterns) privesc modul de creare al obiectelor.

abloane structurale (structural patterns) se refer compoziia claselor sau al obiectelor.

la

abloane comportamentale (behavioral patterns) caracterizeaz modul n care obiectele i clasele interacioneaz i i distribuie responsabilitile.

Clasificarea abloanelor (II)

Dup domeniul de aplicare:
abloanele claselor se refer la relaii dintre clase, relaii stabilite prin motenire i care sunt statice (fixate la compilare). abloanele obiectelor se refer la relaiile dintre obiecte, relaii care au un caracter dinamic.

Cele mai importante abloane

Scop Domeniul de aplicare Clas Factory Method Adapter (clasa) Interface Marker Interface Delegation Adapter (obiect) Bridge Composite Decorator Facade Flyweight Proxy Interpreter Template Method Creaionale Structurale Comportamentale

Obiect

Immutable Abstract Factory Builder Prototype Singleton

Chain of Responsibility Command Interator Mediator Memento Observer State Strategy Visitor

Elemente ce descriu un ablon

Nume: folosete pentru identificare; descrie sintetic problema rezolvat de ablon i soluia.

Problema: descrie cnd se aplic ablonul; se descrie problema i contextul.

Soluia: descrie elementele care intr n rezolvare, relaiile dintre ele, responsabilitile lor i colaborrile ntre ele. Consecine i compromisuri: implicaiile folosirii ablonului, costuri i beneficii. Acestea pot privi impactul asupra flexibilitii, extensibilitii sau portabilitii sistemului, dup cum pot s se refere la aspectele implementrii sau limbajului de programare utilizat. Compromisurile sunt de cele mai multe ori legate de spaiu i timp.

Structura unui ablon (pattern)

Nume i clasificare; Intenie; Problem Motivaie; Aplicabilitate; Structur; Participani; Colaborri; Consecine; Implementare; Cod; Exemplu.

Flyweight Design Pattern

Clasificare:
Dup scop: ablon structural; Dup domeniul de aplicabilitate: ablon al obiectelor. Intenia: Folosete sharing pentru a susine un numr mare de obiecte eficient.

Flyweight Design Pattern

Problem: Proiectarea obiectelor pn la cele mai sczute niveluri ale sistemului, granularitatea ofer flexibilitate optim, dar poate fi inacceptabil de costisitoare n termeni de performan i de utilizare a memoriei. Motivaie: un flyweight reprezint un obiect mprit ce poate fi folosit simultan n contexte multiple. Se comport ca un obiect independent n fiecare context, nu se distinge dintr-o stare a obiectului dac nu este mprit.

Exemplu de folosire a resurselor

Structura claselor pentru obiectele folosite n exemplul de mai sus

Flyweight Design Pattern

Aplicabilitate modelul Flyweight se folosete atunci cnd urmtoarele afirmaii sunt corecte: O aplicaie folosete un numr mare de obiecte; Costul stocrii este mai mare din cauza cantitii mari de obiecte; Aplicaia nu depinde de identitatea obiectului.

Diagrama Claselor

Participanti: Clasele i/sau obiecte care particip la acest model sunt:

Flyweight (Character) declar o interfa prin care ablonul flyweight poate primi i a aciona n stare extrinsec. ConcreteFlyweight (CharacterA, CharacterB, ..., CharacterZ) implementeaz interfaa Flyweight i creeaz depozite pentru starea intrinsec, dac este cazul. Un obiect ConcreteFlyweight trebuie s fie partajat. Orice stare ce este depozitat, trebuie s fie intrinsec, ceea ce nseamna c acestea trebuie s fie independent de contextul obiectului ConcreteFlyweight lui. UnsharedConcreteFlyweight ( not used ) nu toate subclasele Flyweight trebuie s fie mprite. Interfaa Flyweight permite partajarea, dar nu o s pun n aplicare. Aceasta este comun pentru obiectele UnsharedConcreteFlyweight de a avea obiecte ConcreteFlyweight ca fii la un anumit nivel n structura obiectului flyweight (ca n exemplu cu Linii i Coloane). FlyweightFactory (CharacterFactory) creeaz i gestioneaz obiectele Flyweight; asigur c obiectele Flyweight sunt mprite n mod corespunztor. Cnd un client cere un flyweight, obiectele FlyweightFactory activeaz o instan existent sau o creeaz, dac nu exist nici una. Client (FlyweightApp) menine o referin la flyweight(s); evalueaz sau stocheaz starea extrinsec a flyweight(s).

Flyweight Design Pattern

Colaborri:
Clienii nu ar trebui s instanieze ConcreteFlyweight n mod direct Afirmaia ca un flyweight s funcioneze trebuie s fie caracterizat ca intrinsec sau extrinsec.

Consecine:
Cu ct sunt mai multe flyweights mprite, ctigurile de stocare sunt mai mari.
Modelul flyweight este de obicei combinat cu modelul Composite.

Implementarea:
Eliminarea strii extrinsece; Managementul obiectelor mprite.

Flyweight Design Pattern

Flyweight folosete partajarea pentru a sprijini un numr mare de obiecte eficient. Reeaua telefonic public comutat este un exemplu de Flyweight. Aici exist mai multe resurse, cum ar fi generatoarele de ton de apel, generatoare de apel, i receptoare cifre, care trebuie s fie mprite ntre toi abonaii. Un abonat este contient de ct de multe resurse sunt n cont atunci cnd formeaz un numr pentru a efectua un apel. Tot ce conteaz pentru abonai este ca un ton de apel s fie asigurat, cifrele s fie primite, i apelul s fie finalizat.

Exemplu de folosire a ablobului Flyweight

Model View Controller (MVC)

Paradigma MVC se refer la separarea logicii interne a unei aplicaii de partea sa de prezentare, oferind posibilitatea modificrii independente a acestor componente i nlesnind reutilizarea. Cele 3 componente sunt:
model: datele cu care lucreaz aplicaia; view: prezentarea datelor ctre utilizator, de obicei n forma unei interfee grafice. Pot exista mai multe view-uri asociate cu un acelai model. controller: capteaz i proceseaz aciunile utilizatorilor.

Model View Controller (MVC)

Conceptul poate fi perceput la nivel: arhitectural: se refera la structura intregii aplicaii, n care diferitele componente i asum rolurile de mai sus (exemplu: Grails framework) de design: utilizat n contextul unor scenarii mai restrnse (exemplu: componentele vizuale Swing).

Structura ablonului MVC

Model View Controller (MVC)

Principiul care st la baza conceptului Model-View-Controller este mprirea responsabilitilor. ntr-o aplicaie, partea de model va lucra doar cu starea aplicaiei i cu logica ei. Tot aa, partea de "view", este preocupat doar cu crearea interfeei utilizator n funcie de datele i mai ales a schimbrilor strilor acesteia, recepionate de la "model". i n final, "controller"-ul se ocup cu translatarea aciunilor prestate de utilizator n "update"-uri ctre model. Astfel, avem urmtoarea coresponden:

Introducere > Procesare > Rezultat

Controller > Model > View

Fluxul de control al MVC-ului

Interaciunile pot fi: directe (linii continue): apeluri directe de metode ale obiectelor. Exemplu: controller-ul apeleaz metode ale modelului pentru a-l actualiza n urma aciunilor utilizatorului; indirecte (linii ntrerupte): generare i captare evenimente. Exemplu: modelul genereaz un eveniment n momentul unei modificri, ce poate fi captat de view, far ca modelul s fie contient de implementarea particular a acestuia.

Model View Controller (MVC)

Controller"-ul interpreteaz semnalele introduse cu ajutorul "Mouse"-ului i al tastaturii de ctre utilizator i furnizeaz mai departe (ca rezultat) nite comenzi care sunt trimise ctre "model" sau/"viewport" pentru a se putea efectua schimbrile necesare. "Modelul" gestioneaz unul, sau mai multe, elemente ale unei surse de date.
i nu n ultimul rnd "viewport"-ul este partea vizual pentru utilizator a aplicaiei, este gestionarul modului sub care sunt prezentate datele utilizatorului.

Model View ViewModel (MVVM)

Model-View-ViewModel (MVVM) este un design pattern folosit n ingineria software care a fost introdus prima oar de ctre Microsoft ca o metod de particularizare a modelului de prezentare introdus de Martin Fowler. De fapt se pare c Microsoft folosea MVVM pentru proiectele dezvoltate intern, precum Microsoft Expression Blend, pe cnd nucleul platformei WPF era n construcie. Bazat n mare parte pe modelul Model-View-Controller (MVC), acesta se adreseaz n special dezvoltrii interfeei cu utilizatorii a platformelor moderne (HTML5, Windows Presentation Foundation, - WPF, i Silverlight), acolo unde exist un dezvoltator orientat special spre acest lucru, avnd sarcini diferite de ale unui dezvoltator obinuit care se ocup n general de logic business i de dezvoltarea interaciunii cu serverul.

Model View ViewModel (MVVM)

Ca structur, acesta este alcatuit din trei pri eseniale ce pot fi deduse i din denumirea design pattern-ului: Model, View i ViewModel:
Model: Business domain (logica ce ine de domeniul aplicaiei, accesul la date, entiti), View: Interfaa cu utilizatorul PhoneApplicationPage), (n Windows Phone

ViewModel: Modelul View-ului abstractizare a View-ului ce intermediaz comunicarea dintre View i Model.

Model View ViewModel (MVVM)

Aceast structur seamn cu cea a MVC-ului.

Modelul se refer la datele efectiv cu care se lucreaz dar i la nivelul de acces la aceste date. Spre exemplu ntr-un model ar putea fi accesate obiecte care citesc din baza de date informaii legate de o anumit persoan.
View-urile, la fel ca i n cazul clasic se refer la partea vizual care va fi afiata pe interfaa grafic, cum ar fi butoanele, ferestrele, graficele i alte controale. Acestea nu conin partea de logic business. Marele avantaj n acest caz este c un designer poate s se ocupe de partea grafic a aplicaiei lucrnd doar cu view-ul, n timp ce logica din spate rmne neafectat. View-ul comunic doar cu ViewModel-ul, n timp ce ViewModel-ul este privit ca un punct intermediar ntre View i Model. De asemenea, Modelul este singurul care interacioneaz cu baza de date. Acest model are sens n practic doar dac se folosete n combinaie cu o baza de date.

Model View ViewModel (MVVM)

ViewModel-urile reprezinta nite modele pentru view-uri, mai precis acestea se refer la o abstractizare a view-urilor care servesc i la binding-ul datelor ntre view i model. Pot fi privite i ca nite aspecte specializate ale Controalelor din design pattern-ul MVC n aa fel nct s schimbe informaia din formatul modelului n formatul view-ului i s paseze comenzi din view n model. ViewModel-urile expun proprietile publice, comenzile i abstractizrile i au fost asemnate cu o stare conceptual a datelor, spre deosebire de starea real a datelor din model.

Model View ViewModel (MVVM)

S lum un exemplu simplu cu o aplicaie care afieaz dintr-o baz de date informaii despre produse: nume, pre unitar i id. n model va trebui s avem partea de accesare a datelor. Modul n care acestea vor fi accesate rmne la latitudinea programatorului.

Model View ViewModel (MVVM)

ViewModel-ul va conine toat partea de care are nevoie utilizatorul pentru a interaciona cu aplicaia. Aici se pot pune sortrile, tergerile din list sau orice alte operaiuni necesare. n cazul de fa doar 2 comenzi, GetProduct i SaveProduct ce vor fi folosite pentru a aduce un obiect din model n viewmodel i pentru a salva un produs, acestea sunt de tipul ICommand.

Sintaxa comenzilor GetProduct i SaveProduct de tipul Icommand (MVVM)

Tot aici apare i clasa RelayCommand, esenial pentru ca MVVM s funcioneze. Aceasta conine o comand ce va fi executat de alte clase pentru a rula cod n clasa de baz prin invocarea de delegates.
public ICommand SaveProductCommand{ get{ if (_saveProductCommand == null) { _saveProductCommand = new RelayCommand(param => SaveProduct(), param => (CurrentProduct != null));

}
return _saveProductCommand; } }

Model View ViewModel (MVVM)

View-ul este partea care definete modul n care va arta aplicaia. De asemenea se vor defini dou DataTemplate-uri, unul pentru model i unul pentru viewmodel.
Pentru a porni aplicaia mai trebuie adugate urmtoarele linii de cod n App.xaml.cs, care creaz ViewModel-ul i asociaz datacontext-ul ferestrei n viewmodel: MainWindow app = new MainWindow(); ProductViewModel viewModel = new ProductViewModel();

app.DataContext = viewModel; app.Show();

Model View ViewModel (MVVM)

Dei structura lui este una logic i ofer organizare n cod, acesta nu se preteaz pentru orice fel de proiect. Dac avem de-a face cu un proiect unde nu exist o interfa grafic prea complex nu se prea justific folosirea MVVM, codul putnd fi scris chiar i n code behind. De asemenea unii programatori nu recomand folosirea acestui pattern dac nu se dorete realizarea de unit-teste. ntruct uurina n scrierea testelor este unul din avantajele acestuia, este de preferat ca acesta s fie folosit doar mpreun cu acestea. Este total neproductiv i deci nu este recomandat folosirea unui design pattern ntr-o aplicaie simpl Hello World! n concluzie MVVM ofer anumite avantaje precum separarea view-ului de logica business i uurina n scrierea testelor unitare, ns programatorii trebuie s fie ateni dac acest design pattern se preteaz sau nu pentru proiectul lor.

Cum se folosete (MVVM) ?

S considerm o aplicaie n care dorim s introducem persoane ntr-o anumit list. Partea de Model n aplicaia noastr este compus dintro singur clas, Persoana.

Partea de View este compus dintr-o singur fereastr, AdaugarePersoaneView.xaml.

n fereastr avem o list care afieaz persoanele adugate, dou textbox-uri (pentru numele i prenumele persoanei ce urmeaz s fie adugat, i un buton, pentru adugarea persoanei n list). Dup cum se poate observa, la seciunea de resurse se definete o instan de model, care este setat ca i DataContext. Modelul arat astfel:

Clasa DelegateCommand.
n cazul n care nu dorim ca s folosim propagarea comenzii prin arborele visual, putem s ne creem o clas proprie care implementeaz ICommand, i s furnizm instane de metode (delegates) pentru Execute i CanExecute. n acest caz putem fi siguri care sunt metodele care se apeleaz. Dac nu nregistrm handleri n contextul actual al controlului, atunci nu se va rula nici un cod. Totul se ntmpl local, i este foarte uor de urmrit.