Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE





AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml


Problematica Design Patterns in ABAP Objects

java

+ Font mai mare | - Font mai mic







DOCUMENTE SIMILARE

Trimite pe Messenger
Problematica Design Patterns in ABAP Objects

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.

la nivel de clasa

DPCR amana procesul de creare la subclase

la nivel de obiect

DPCR intarzie procesul de creare la alte obiecte

  • DP-urile structurale (DPST)

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

la nivel de clasa

DPST impun crearea structurilor prin paradigma mostenirii

la nivel de obiect

DPST impun realizarea structurilor prin referinte la alte obiecte

  • 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

la nivel de clasa

DPCO realizeaza aspectele mentionate prin paradigma mostenirii

la nivel de obiect

DPCO descriu modul de colaborare al obiectelor ptr. a indeplini anumite sarcini

2           Clasificarea Gamma Pattern-urilor1

Sfera de actiune Scop

Creational

Structural

Comportamental

Clasa

Factory Method

Adapter (class)

Interpreter

Template method

Obiect

Abstract Factory

Builder

Prototype

Singleton

Adapter (object)

Bridge

Composite

Decorator

Façade

Flyweight

Proxy

Chain of Responsibility

Command

Iterator

Mediator

Memento

Observer

State

Strategy

Visitor

comportamental

Observer

Model

structural

Composite

View

comportamental

Strategy

Control

3           Simboluri UML


Reprezentare

Denumire

Exemplu cod ABAP



Clasa

CLASS a DEFINITION.

ENDCLASS.

CLASS a IMPLEMENTATION.

ENDCLASS.

Interfata

INTERFACE a.

ENDINTERFACE.

Mostenire

CLASS a DEFINITION.

ENDCLASS.

CLASS b DEFINITION INHERITING FROM a.

ENDCLASS.

Realizare

INTERFACE a.

ENDINTERFACE.

CLASS b DEFINITION.

INTERFACES:

a.

ENDCLASS.

Dependenta

CLASS a DEFINITION.

ENDCLASS.

CLASS b IMPLEMENTATION.

CREATE OBJECT lr_a TYPE a.

ENDCLASS.

Asociere

CLASS a DEFINITION.

ENDCLASS.

CLASS b IMPLEMENTATION.

DATA lr_a TYPE REF TO a.

ENDCLASS.

Agregare

CLASS ring DEFINITION.

ENDCLASS.

CLASS finger DEFINITION.

DATA ca_ring TYPE REF TO ring.

ENDCLASS.

Compozitie

CLASS finger DEFINITION.

ENDCLASS.

CLASS hand DEFINITION.

DATA ca_thumb TYPE REF TO finger.

ENDCLASS.

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).

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

ConcreteSubject

Observer

ConcreteObserver


Colaborari:

·         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.

Subject

lcl_Stock

ConcretSubject

lcl_Ibm

Observer

lif_Investor

ConcreteObserver

lcl_Investor

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

Leaf



Composite

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.

  1. 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.

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

  1. 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.

Component

lcl_DrawingElement

Leaf

lcl_PrimitiveElement

Composite

lcl_CompositeElement

Client

lcl_Application

Diagrama de clase UML:



1 Gamma, Helm, Johnson, Vlissides, Design Patterns: Elements of Reusable Object Oriented Software








Politica de confidentialitate

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 667
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site