Problematica Design Patterns in ABAP Objects

1           Gamma Patterns

• un prim set de pattern-uri, si probabil si cele mai cunoscute, sunt cele conturate in cartea GoF, Design Patterns: Elements of Object Oriented Software cunoscute si sub numele de Gamma Patterns. Autorii acestei carti au conturat un set de 23 de modele de proiectare pe care le impart in 6 categorii in functie de scopul si sfera de actiune a lor.

• DP-urile creationale (DPCR)

-        trateaza teme legate de instantierea obiectelor.

• DP-urile structurale (DPST)

-        abordeaza aspecte intalnite la structura (compunerea) obiectelor si a claselor.

• DP-urile comportamentale (DPCO)

-        releva chestiuni legate de distribuirea responsabilitatilor intre obiecte si clase.

-        definesc felul in care are loc comunicarea intre clase si obiectele

-        determina responsabilitatile acestora in procesul de comunicare

2           Clasificarea Gamma Pattern-urilor1

3           Simboluri UML

3.1          Observer

Intentie: Este folosit pentru a realiza o comunicare intr-o singura directie intre un obiect (cel ce e observat) si mai multe obiecte (cei care observa).

Astfel la modificarea starii obiectului observat, observatorii pot fi anuntati de modificarea observatului, si pot lua masuri in acest sens.

Cunoscut si ca: Dependents, Publish-Subscribe

Frecventa de folosire:

Aplicabilitate:

o        cand se doreste refolosirea unei abstractii, care are doua aspecte dependente una de cealalta, incapsularea lor separata in obiecte distincte permite reutilizarea independenta a acestora

o        cand in urma modificarii unui obiect este necesara modificarea altor obiecte, fara ca sa se stie numarul exact al acestora

o        cand se doreste o legare detasata a mai multor obiecte, si totusi a mentine abilitatea de a comunica fara a cunoaste, insa, obiectele acestea

UML:

Participanti:

Subject

-          isi cunoaste observatorii

-          ofera o interfata pentru a atasa si a detasa obiecte de tip Observer

ConcreteSubject

-          stocheaza starea de interes

-          trimite o notificare la toti observatorii cand starea sa se modifica

Observer

-          defineste o interfata pentru a aduce la curent obiecte care sa fie notificate cand cel observat isi modifica starea

ConcreteObserver

-          mentine o referinta la ConcreteSubject

-          stocheaza starea care trebuie sa fie consistenta cu cea din obiectul observat

-          implementeaza interfata din Observer pentru a se tine la curent cu starea subiectului

Colaborari:

o        ConcreteSubject notifica Observer ori de cate ori are loc o modificare in starea proprie pentru a nu exista inconsistente in informatia dintre cele doua.

o        Dupa informarea Observer despre schimbare, acesta poate sa ceara de la Subject informatii. Aceste informatii sunt folosite pentru a-si revizui propria stare.

Consecinte:

1. Cuplare abstracta intre Subject si Observer. Tot ce stiu subiectii este ca au o lista de observatori, care se conformeaza unei interfete comune. Subject nu stie nimic de clasele concrete Observer, astfel cuplarea dintre cele doua clase fiind minima.

2. Comunicare raspandita. Spre deosebire de cererile obisnuite, notificarea trimisa de un subiect nu trebuie sa specifice un destinatar anume. Aceasta este trimisa la toate obiectele interesate, care trebuie in prealabil sa-si subscrie aceasta dorinta. Singura responsabilitate a Subject este sa notifice toate obiectele subscrise, indiferent de numarul acestora. Acest aspect permite introducerea sau scoaterea Observer la orice moment. Fiecare Observer poate sa trateze sau sa ignore cererea primita.

3. Actualizari neasteptate. O operatie care la prima vedere pare nevinovata poate lansa o cascada de actualizari catre Observer-ele sale. Daca aceste dependente nu sunt definite bine se pot lansa o serie de actualizari false. Acest protocol nu ofera nici o informatie referitor la ce s-a schimbat in Subject. Responsabilitatea de a detecta ce anume s-a schimbat revenind Observer-ului care va trebui sa efectueze analize amanuntite pentru deducerea schimbarilor.

Pattern-uri Inrudite:

         Prin incapsularea intr-un singur obiect a unui scenariu de actualizare, acest obiect va fi un Mediator intre subiect si observatorii sai.

         Un asemenea "Mediator" este implementat ca un Singleton pentru a fi unic si accesibil global.

Implementare: Y_DP_OBSERVER

Consideram o bursa de valori. Se doreste monitorizarea starii actiunilor unei companii anume pentru a investi in momentele cele mai oportune.

Solutia clasica ar fi apelarea secventiala dupa fiecare modificare a pretului a metodelor obiectelor care sunt interesate de modificare. Solutia insa este mult prea inflexibila pentru a putea fi folosita.

Este necesara o cuplare mai detasata in cazul in care sistemul trebuie supus unei modificari, acesta sa nu implice modificarea intregului sistem.

O astfel de modificare ar fi dorinta de a adauga un nou investitor care doreste sa monitorizeze starea actiunilor unei anumite companii.

Observer permite monitorizarea starii actiunilor companiei si in acelasi timp mentinerea unei legari detasate intre obiectul observat (lcl_IBM) si obiectele care observa (lcl_Investor).

Interfata abstracta lcl_Stock ofera metode pentru a atasa si a detasa observatori, si mentine o lista a obiectelor care trebuie notificate.

Interfata abstracta lif_Investor are rolul de a defini o metoda prin care sa se actualizeze cand subiectul observat isi schimba starea.

Subiectul concret, lcl_IBM mentine starea de interes si implementeaza interfata abstracta lcl_Stock.

De asemenea subiectul concret este responsabil cu lansarea operatiei de actualizare la modifacarea starii de interes.

Observatorul concret, lcl_Investor, implementeaza interfata abstracta prin care se actualizeaza la modificarea subiectului observat, si mentine o referinta la acesta pentru ca dupa notificare sa-si poata revizui starea.

Exemplul ilustreaza usurinta cu care se pot adauga noi observatori si modul in care sunt acestia notificati in cazul modificarii obiectului observat, lcl_Ibm.

Diagrama de clase UML

3.2          Composite

Intentie: Compune obiecte in structuri de tip arbore pentru a obtine ierarhii. Este folosit cand clientul doreste tratarea uniforma un obiect individual precum si a obiectelor compuse.

Frecventa de folosire:

Aplicabilitate:

o        cand se doreste reprezentarea unor ierarhii de obiecte

o        cand se doreste ca sa nu se poata diferentia intre obiecte simple si obiecte compuse de catre clienti, acestia fiind nevoiti sa le trateze uniform

Participanti:

Component

-          declara o interfata pentru obiectele din compozitie

-          implementeaza comportamentul standard pentru toate clasele din compozitie

-          declara o interfata pentru acces si manuirea copiilor sai

-          optional poate sa defineasca o interfata pentru accesul la parinte si poate sa si implementeze aceasta operatie

Leaf

-          reprezinta o frunza in compozitie. Frunzele nu au copii

-          defineste comportamentul obiectelor primitive din compozitie

Composite

-          defineste comportamentul componentelor care pot sa aibe copii

-          stocheaza proprii copii

-          implementeaza operatii specifice copiilor din interfata Component

Client

-          utilizeaza obiecte din compozitie prin interfata Component

Colaborari:

o        Clientii folosesc interfata clasei Component pentru a interactiona cu structura de obiecte. Daca destinatarul este o frunza, atunci cererea este tratata, daca destinatarul este un Composite, atunci, in general, cererea este inaintata la copii sai. Composite are ocazia ca inainte si dupa trimiterea cererii sa efectueze diferite operatii.

Consecinte:

1. Ierarhii de clase. Composite defineste ierarhii de clase de obiecte simple si obiecte compuse. Obiectele primitive pot fi compuse in obiecte mai compuse care la randul lor pot sa compuna alte obiecte. Procedura este recursiva. Un client care se asteapta la un obiect primitiv, poate primi ca parametru un obiect compus.

2. Simplificarea clientului. Clientii pot sa trateze uniform obiectele simple si cele compuse. Clientii sunt absolviti de responsabilitatea cunoasterii tipului de obiect cu care lucreaza, ce duce la simplificarea codului.

3. Simplificarea procesului de adaugare de noi componente. Subclasele Composite si Leaf functioneaza cu structurile existente, fara a fi necesara modificarea clientilor.

4. Proiect prea general. Dezavantajul acestui pattern este ca este greu in a restrictiona componentele Composite. Uneori se v-a dori ca numai anumite componente sa poata sa faca parte din Composite. Pentru aceasta vor trebui facute verificari in timpul de executiei.

Pattern-uri inrudite:

         Legatura componenta parinte este folosita pentru Chain of Responsibility

         Decorator este folosit pentru a completa interfata Composite.

         Flyweight permite impartasirea obiectelor componente, dar se pierde referinta catre parinti.

         Interator permite traversarea unui Composite

         Visitor separa operatii si comportament care de altfel ar fi distribuit in subclasele Composite si Leaf

Implementare: Y_DP_COMPOSITE

Consideram un sistem format din mai multe elemente simple (lcl_PrimitiveElement) sau compuse (lcl_CompositeElement). Elementele compuse pot fi formate din unul, mai multe sau nici un alt element. Acestea se doresc incluse intr-o structura ierarhica.

Solutia clasica este de a construi clase diferite pentru tipurile de elemente iar clientii sa foloseasca acestea in implementarea lor. Pentru constituirea ierarhiei se pot alege diferite reprezentari ca graf, arbore sau lista.

Solutia clasica are, insa, anumite dezavantaje: in primul rand avem multe informatii de control necesare reprezentarii. Aici de la caz la caz avem referinte la parinte-fiu, referinte la succesor sau predecesor sau altele, toate duc la incarcarea codului. De operatiile de adaugare respectiv suprimare vor avea un grad de dificultate mai mare.

Clientul v-a trebui sa prevada pentru fiecare tip de element un caz separat de tratare ce v-a atrage dupa sine blocuri mari de instructiuni conditionale. Acestea se doresc evitate deoarece in cazul chiar si a micilor modificari necesita adaptare, iar refolosirea lor este de multe ori imposibila.

DP Composite permite construirea unor structuri ierarhice si in acelasi timp ofera si o interfata unica atat pentru obiecte simple cat si cele compuse. Component, lcl_DrawingElement, defineste o interfata pentru toate obiectele din compozitie, cu metode de adaugare, add( ), suprimare, remove( ), si afisare, display( ). Acestea vor trebui implementate de fiecare tip de element care doreste sa poata fi folosit in ierarhie.

Prin aceasta, clientii care folosesc ierarhia nu vor diferentia intre obiecte simple (lcl_PrimitiveElement) si obiecte compuse (lcl_ComponentElement), eliminand necesitatea blocurilor conditionale. Ierarhia contine mai putine elemente de control, insa, daca acest lucru este necesar, se pot mentine anumite informatii suplimentare, ca de exemplu o referinta la parinte.

Un mic inconvenient ar aparea in cazul in care am dori sa restrictionam adaugarea anumitor tipuri de elemente la ierarhie. Acest lucru este o consecinta directa a necesitatii tratarii obiectelor uniform, adica necesitatii generalizarii. Pentru a depasi acest aspect se poate insa folosi sistemul RTTI (RunTime Type Identification) pus la dispozitie de platforma Netweaver.

Diagrama de clase UML: